[PATCH] D53794: [TargetLowering] expandFP_TO_UINT - avoid FPE due to out of range conversion (PR17686)

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

kpn added a comment.

In https://reviews.llvm.org/D53794#1278834, @uweigand wrote:

> Now, the solution suggested in **this** patch is also interesting since it can be done without introducing new basic blocks (and therefore can be done in SelectionDAG, without needed a new pass).  However, in order to generate efficient code we probably still need to get to the same assembler code we'd have gotten from that new pass -- but now instead the burden is on the back-end to recover the if-then-else block from a series of select statements.  Not sure what is better here.


But does this actually solve the issue with FP traps, or does it just mask it? What's to stop llvm from reordering the selects and bringing back the trap?

> In any case, the current code I see e.g. in the SystemZ tests is definitely worse than what we have today.

Does this patch prevent llvm from introducing traps? If no, what is the benefit from a change that doesn't eliminate the problem and produces worse code?


Repository:
  rL LLVM

https://reviews.llvm.org/D53794