[Mlir-commits] [mlir] [mlir][SPIR-V] Lower arith.convertf to widen-then-narrow FConvert pair (PR #212817)

Arseniy Obolenskiy llvmlistbot at llvm.org
Mon Sep 21 02:41:12 PDT 2026


aobolensk wrote:

> > spirv.FConvert requires differing component widths, so f16<->bf16 casts must bridge through f32 rather than converting directly
> 
> Where does it come from? Looking at the spec it says:
> 
> > The component type must not equal the component type in Result Type.
> 
> And also in `4.45. Changes from Version 1.6, Revision 3` it says:
> 
> > Clarify that OpFConvert operates on different types not just width.
> 
> So it sounds to me like conversion between `f16` and `bf16` is legal.

I have taken that from [SPV_KHR_bfloat16](https://github.khronos.org/SPIRV-Registry/extensions/KHR/SPV_KHR_bfloat16.html) spec:

For Conversion Instructions paragraph it says:

> Conversions to or from floating-point values with the `BFloat16KHR` encoding first convert the source value to IEEE754 binary32, and then from IEEE754 binary32 to the target format.
> When converting from `BFloat16KHR` to IEEE754 binary32, the additional significand bits are padded with 0s, producing the exact same value.
> When converting from IEEE754 binary32 to `BFloat16KHR`, the rounding mode is defined by the client API.


https://github.com/llvm/llvm-project/pull/212817


More information about the Mlir-commits mailing list