[Question / Feature Request] Translation of floating point canonicalize (`@llvm.canonicalize`)

[Maetveis]

The @llvm.canonicalize intrinsic is not supported by the bi-directional translator or the LLVM SPIR-V backend.
This is a basic intrinsic that is very useful in floating point math libraries, and ideally all LLVM backend should support it. LLVM's libclc uses it extensively for targets other than SPIR-V, having SPIR-V support the instruction would simplify the library code.

I've attempted an implementation in llvm/llvm-project#178439, but I've run into issues. I would like to ask for help on what might be a reasonable lowering. The options I considered:

Option 1

Lower @llvm.canonicalize(x) -> OpFMul / OpVectorTimesScalar x, 1.0. Motivated by the sentence in the LLVM language reference "This function should always be implementable as multiplication by 1.0".
This is the approach taken in llvm/llvm-project#178439. According to my understanding of the spec however, the SPIR-V consumer is allowed to optimize this away.
This happens in practice, the reverse translation of OpFMul x, 1.0 is fmul x, 1.0, which is then folded by LLVM middle-end optimization passes (InstSimplify).
This could be worked around by special-casing OpFMul x, 1.0 to translate to @llvm.canonicalize, thereby preserving the semantics. OpFMul x, 1.0 could theoretically show up naturally in IR, not just from llvm.canonicalize, in which case we'd be pessimizing code. It also does not address SPIR-V consumers that do not translate to LLVM-IR.

Option 2

Lower to a different "identity" floating point instruction, hopefully one that is not folded out by LLVM transformations. For example fmin x, x from the OpenCL extended instruction set. Using these might hurt performance: the reverse translation is to call a function fmin or __spirv_fmin, this is going to optimize much worse than llvm.canonicalize.

Option 3

Explicitly support floating point canonicalization instruction in SPIR-V via an extension. This would be the cleanest approach. The semantics of such an instruction would have to be defined for what makes sense for SPIR-V.

[svenvh]

A dedicated SPIR-V extension sounds like the cleanest and most robust option to me. Any solution relying on special casing certain IR patterns is fragile and will likely break numerous times in the future.

[kwk]

Is there any update on this issue?

[Maetveis]

Is there any update on this issue?

No significant update. I have thought about starting to write a proposed extension, but I'm not sure when I'd have the bandwidth to do that.

[bashbaug]

Couple of thoughts:

1. We should think of a potential fallback that does not require a new SPIR-V extension, even if it's slow, since it will take some time for support to be widespread even if we do end up with a dedicated extension. This would also help to justify why a new extension is needed, since we would be able to quantify the performance with the fallback vs. dedicated support.
2. Can you provide any more information about the math libraries you referred to that are using this intrinsic? This would also help to justify why a new extension is needed.

Thanks!

[Maetveis]

Can you provide any more information about the math libraries you referred to that are using this intrinsic? This would also help to justify why a new extension is needed.

Sure, this was motivated by usage in libclc, an implementation of the library parts of OpenCL.
There, it id used to conditionally flush denormals when emulating some floating point operations using bitwise manipulation. When denormal flushing is enabled in the environment we flush otherwise don't. To check if denormals are being flushed the library would like to do x == llvm.canonicalize(x), but can't because llvm.canonicalize is not supported.

Another example is llvm/llvm-project#177131, which would have been an improved (more correct) implementation of remquo that had to be reverted due to missing llvm.canonicalize support in SPIR-V.

We should think of a potential fallback that does not require a new SPIR-V extension, even if it's slow, since it will take some time for support to be widespread even if we do end up with a dedicated extension.

I can think of 2 possible fallbacks

1. Basically option 2 from above, an "identity" floating point operation like fmin(x,x).
2. expand the intrinsic to flush denormals and quit signaling nans, using the equivalent llvm.isfpclass and OpSelect.

The problem with 2 is that without DenormFlushToZero, DenormFlushToZero or SignedZeroInfNanPreserve from SPV_KHR_float_controls it is up to the implementation (and client API) to decide how denormals are to be handled, so the SPIR-V emitter (be it the translator or the llvm backend) cannot know what to do.