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

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 26 18:35:37 PDT 2019


craig.topper added a comment.

In D63782#1560123 <https://reviews.llvm.org/D63782#1560123>, @cameron.mcinally wrote:

> In D63782#1559964 <https://reviews.llvm.org/D63782#1559964>, @efriedma wrote:
>
> > > I think IEEE-754 does define this
> >
> > Your citation doesn't actually specify what value is returned, only that an exception is raised.
>
>
> Ok, I agree with that:
>
>   The invalid operation exception is signaled if and only if there is no usefully definable result.
>
>
> So pragmatically, an invalid exception is an alarm that the code is off track. As long as the exception is handled appropriately (default or an alternative), the result of the invalid operation shouldn't matter. Whatever LLVM wants to do with the value gets no arguments from me, since we've already self-destructed (unless the program handles the exception gracefully, but that wouldn't require a defined result from the invalid operation anyway).


But the exception could be masked couldn't it?

> Thinking about LangRef, aren't all the constrained intrinsics special considering the side-effects? Would it be acceptable for LangRef to read something like:
> 
>   Semantics:
>   
>   @llvm.experimental.constrained.fadd maps to IEEE-754's addition(x, y)
> 
> 
> [Also, I'm noticing that the LangRef semantics for the existing constrained intrinsics are pretty sloppy. Those will probably need to be reworked.]




Repository:
  rL LLVM

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

https://reviews.llvm.org/D63782





More information about the llvm-commits mailing list