Support ClampStochasticRound FP16/BF16 to E2M1

[vmaksimo]

Add missing support of Float4/E2M1 as a valid destination type for OpClampStochasticRoundFToFINTEL builtin - the only thing left to fully support SPV_INTEL_fp_conversions extension.

Updated the design doc accordingly.

Spec:
https://github.com/intel/llvm/blob/sycl/sycl/doc/design/spirv-extensions/SPV_INTEL_fp_conversions.asciidoc

AI-assisted: Claude Sonnet 4.6 (commercial SaaS)

[YuriPlyakhin]

LGTM

[MrSidims]

Aren't we always clamping (per OCP spec) when converting to E2M1?

[vmaksimo]

Aren't we always clamping (per OCP spec) when converting to E2M1?

@MrSidims do you mean, should clamping happen even for __builtin_spirv_StochasticRoundFP16ToE2M1INTEL?

I'm actually not sure how to treat the OCP MX spec here:

During conversion to FP4, if a value exceeds the FP4 representable range after rounding, an
implementation must support clamping (saturating) the value to the maximum FP4 magnitude,
preserving the sign. Other methods may be supported, with a configurable overflow attribute to
choose between available methods. Out-of-range values can be normal numbers or Infs in a wider
data format.

[vmaksimo]

@MrSidims friendly-ping, have i answered your concern/question?

[MrSidims]

Ah, my review is not blocking here. It makes sense to add missing instructions.

I'm just trying to clarify this. Because, lets say, ConvertFP16ToE2M1INTEL and ClampConvertFP16ToE2M1INTEL are (per my understanding) effectively the same instruction. And if anybody claims other way - they would need to answer uncomfortable question about "to what value Inf is being converted?".

[vmaksimo]

Thanks, Dmitry!
I also assume that these two names act as aliases of the same instruction - just for the naming consistency with the conversion instructions to other types.
I'll rase the question internally to confirm, and if needed we'll follow-up on spec/implementation.

For now I see no blocks for merging, thanks for clarifying that.