[PATCH] D63782: [FPEnv] Add fptosi and fptoui constrained intrinsics

[Cameron McInally via Phabricator via llvm-commits]

cameron.mcinally added a subscriber: eli.friedman.
cameron.mcinally added a comment.

In D63782#1573780 <https://reviews.llvm.org/D63782#1573780>, @kpn wrote:

> In D63782#1561585 <https://reviews.llvm.org/D63782#1561585>, @andrew.w.kaylor wrote:
>
> > I might be opening a can of worms here and I'm not a language expert, but it isn't clear to me from reading the C99 standard that defining fptosi/fptoui as returning poison values in the unrepresentable case allows correct implementation of the C standard. That is, it doesn't seem to me that the standard actually says this is undefined behavior. It just says the resulting value is unspecified, and the exception behavior is explicitly defined. On the other hand, C++ does say clearly that it is undefined behavior, right?
>


It looks like it is undefined behavior in a recent(-ish) draft of the C Standard:

  6.3.1.4 Real floating and integer
  
  1 When a finite value of real floating type is converted to an integer type other than _Bool, the fractional part is discarded (i.e., the value is truncated toward zero). If the value of the integral part cannot be represented by the integer type, the behavior is undefined.

And it also appears to be UB in a draft of the C++ Standard:

  7.10 Floating-integral conversions
  
  1 A prvalue of a floating-point type can be converted to a prvalue of an integer type. The conversion truncates; that is, the fractional part is discarded. The behavior is undefined if the truncated value cannot be represented in the destination type.



>> I understand that in the unconstrained case LLVM doesn't care about FP exceptions and that we would like the LLVM IR definition to be more precise than the C standard. I'm just trying to get my head wrapped around why we're doing what we are in that case and what we need to do to correctly implement strict FP semantics.
>> 
>> If we say that the constrained version returns undef in the unrepresentable case and clearly emphasize how this differs from the standard fptosi/fptoui instructions, would that have the effect of keeping the operation around so that it can raise the exception while still giving us well-defined IR semantics?

I'd be okay with a constrained fptoXi returning poison, as long as the operation isn't replaced by a poison value. In other words, what happens after the trap (and processing) is immaterial, so it's fine for the compiler to treat it as undefined behavior.

How aggressive is LLVM's UB handling? Would it remove an entire block/function if UB is found in it? @eli.friedman


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63782