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

[Kevin P. Neal via Phabricator via llvm-commits]

kpn added a comment.

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

> In D63782#1560136 <https://reviews.llvm.org/D63782#1560136>, @craig.topper wrote:
>
> > In D63782#1560123 <https://reviews.llvm.org/D63782#1560123>, @cameron.mcinally wrote:
> >
> > > 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?
>
>
> Yeah, but I'm not sure if it matters. The program has already failed, so there's no guarantee that the results are useful.
>
> Our typical user enables traps (inv, divz, and ovf) during development to convince themselves that the code is safe. Production runs are then done with traps disabled. But, of course, traps may be reenabled if a runtime problem is later found. They're basically a sanity check.


We run with traps _on_, except we don't care about Inexact, and we do this in the products that ship to customers. Traps get handled in some way that is reasonable to a higher level of the software, for example by at least sometimes having a handler insert a value to replace the value that didn't get produced by the instruction that trapped. So I want a constrained fptoXi that is given valid inputs to never generate poison or get folded in a way that hides a trap.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63782