[llvm-dev] [FPEnv] undef and constrained intrinsics?

[Kevin Neal via llvm-dev]

How should the constrained FP intrinsics behave when called with an operand that is "undef" and the FP environment is _not_ the default environment? I'm specifically working in the middle end passes if it matters. Let me start with the assumption that the rounding mode is not relevant. That still leaves the exception handling as a factor:

With "fpexcept.maytrap" we are allowed to drop instructions that could or would cause a trap at run-time. Does this imply we can fold the entire instruction to a new undef?

With "fpexcept.strict" we are _not_ allowed to lose or reorder traps. So how does that affect undef? What happens in the backend? Perhaps the middle end should leave the instruction with the undef and let the backend do something reasonable?

The "maytrap" case is the one I'm most interested in. An earlier version of D103169 would fold away undef constrained intrinsics in the maytrap case. This was removed so it could be handled without affecting the rest of the patch I believe.

Opinions?
--
Kevin P. Neal
SAS/C and SAS/C++ Compiler
Compute Services
SAS Institute, Inc.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210709/02d950ef/attachment.html>