[PATCH] D115804: [CodeGen] use saturating FP casts when compiling with "no-strict-float-cast-overflow"

Tue Dec 21 10:35:24 PST 2021

kpn added a comment.

In D115804#3202479 <https://reviews.llvm.org/D115804#3202479>, @sepavloff wrote:

> In D115804#3201681 <https://reviews.llvm.org/D115804#3201681>, @spatel wrote:
>
>> In D115804#3201044 <https://reviews.llvm.org/D115804#3201044>, @craig.topper wrote:
>>
>>> What's the plan for constrained intrinsics versions of these intrinsics? The IRBuilder calls for CreateFPToSI and CreateFPToUI are strict FP aware, but this new code isn't.
>>
>> Not sure. cc'ing @kpn @sepavloff @andrew.w.kaylor  
>> The saturating intrinsics implement non-standard behavior for C languages AFAIK, so we might want to warn if someone tries to use "-fno-strict-float-cast-overflow" and "-ffp-exception-behavior=strict" at the same time? Or we try to support that corner case by adding even more FP intrinsics?
>
> Conversion `float`->`int` depends on rounding mode. At least on some ML cores this conversion is made with saturating semantics. So ability to specify rounding mode would be useful for such targets.

What about the idea of using operand bundles? I think the idea there was to avoid having to add new intrinsics for every target-specific floating point intrinsic. But maybe the idea will work here as well?

I think we definitely need to warn when -ffp-exception-behavior=strict or =maytrap is given and incompatible options are also used with it. In that case we should also be disabling the -ffp-exception-behavior option and the related #pragmas plus warning about the disabling. We already disable+warn when our backend doesn't support strictfp, we can do the same here.

If someone in the future wants to implement the support then that'll be nice. But in the meantime we shouldn't be silently letting people use strictfp plus a contradictory option.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115804/new/

https://reviews.llvm.org/D115804