[PATCH] D41338: [CodeGen] lower math intrinsics to finite version of libcalls when possible (PR35672)

[Andy Kaylor via Phabricator via llvm-commits]

andrew.w.kaylor added a comment.

After thinking through this particular situation a bit more with regard to the STRICT_EXP node, I think what you've chosen to do here is probably correct. I'm not entirely certain what the __exp_finite implementation does, but I would expect that with regard to rounding it will produce the same result as the normal function as long as the input is finite. Similarly, I think that the exception behavior of __exp_finite should be the same as the non-finite version as long as the input is finite. If the input is non-finite, then I would expect that the appropriate exception was raised or status flag set by whatever produced the value. I don't think either exp or __exp_finite will produce an exception for non-finite values. We'll get the wrong answer with __exp_finite of course, but the user signed up for that when using the fast math flags.

In general, as this implementation approach is propagated to other functions, I think this is the questions we need to ask. Will the finite version hide exceptions that would have been raised by the normal function call or produce exceptions that wouldn't have been produced otherwise? I'd need to look into each function implementation, but I can imagine cases where assuming finite inputs could lead to changes in exception behavior.


https://reviews.llvm.org/D41338