[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