[llvm-dev] Combining fast math flags with constrained intrinsics

[Cameron McInally via llvm-dev]

On Tue, Jan 21, 2020 at 1:08 PM Finkel, Hal J. <hfinkel at anl.gov> wrote:
>
>
> On 1/21/20 11:59 AM, Kaylor, Andrew wrote:
> >> with the caveat that I don't think NNAN and NINF make sense for any trap-safe mode
> > I said this in my original message, but I'd like to reiterate it here. I think it does make sense to combine these with the trap-safe modes. It's an optimization. It's not saying we don't care about NaN and inf. It's asserting that they will not occur. This definitely gives the user the ability to shoot themself in the foot, but really no more so than these flags do in the non-constrained case. If the user is certain that their data and algorithms will never result in NaNs or infinities, we can optimize the code slightly better even in trap-safe modes than we could if we had to allow for the possibility of NaNs and infinities. Obviously, this can lead to missed exceptions and even incorrect results, but it can lead to incorrect results in the non-constrained case too. It's a risky option.
>
>
> +1
>
> We should consider these orthogonal concepts at the LLVM level, because
> they are logically orthogonal. I recommend that Clang also consider them
> to be orthogonal. If some frontend wants to consider them mutually
> exclusive in the context of a particular language, or warn about them in
> some way, that's a choice that frontend certainly has -- users aren't
> generally writing LLVM directly.

That's fair.