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

[Finkel, Hal J. via llvm-dev]

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.

  -Hal


>
>
> Overall, the picture I'm getting is that we need to have some sort of table of FP semantic modes and document which ones we consider orthogonal, which ones we consider mutually exclusive, and what effects various pragmas will have on each of them. Melanie worked through a lot of these issues in her patch to add the -fp-model and related command line options. Maybe we can generalize that to our reasoning about the IR and put it in the language ref.
>
> -Andy
>
> -----Original Message-----
> From: Cameron McInally <cameron.mcinally at nyu.edu>
> Sent: Saturday, January 18, 2020 7:25 AM
> To: Finkel, Hal J. <hfinkel at anl.gov>
> Cc: Kaylor, Andrew <andrew.kaylor at intel.com>; LLVM Developers Mailing List <llvm-dev at lists.llvm.org>; cfe-dev at lists.llvm.org; Kevin Neal <Kevin.Neal at sas.com>; Ulrich Weigand (Ulrich.Weigand at de.ibm.com) <Ulrich.Weigand at de.ibm.com>; Wang, Pengfei <pengfei.wang at intel.com>; John McCall (rjmccall at apple.com) <rjmccall at apple.com>; Arsenault, Matthew <Matthew.Arsenault at amd.com>; Serge Pavlov <sepavloff at gmail.com>; Blower, Melanie I <melanie.blower at intel.com>; Sanjay Patel <spatel at rotateright.com>; Stephen Canon <scanon at apple.com>
> Subject: Re: Combining fast math flags with constrained intrinsics
>
> On Fri, Jan 17, 2020 at 8:09 PM Finkel, Hal J. <hfinkel at anl.gov> wrote:
>> Andy, thanks for writing this up. A few thoughts:
>>
>>   1. The mental model that I have is that there is always an FP_CONTRACT pragma: there's some default (implicit) pragma at the beginning, and what it says (off/on/fast) is controlled by the command-line flags (or the driver's default if no flags are explicitly provided). Thus, unless there's some reason my model doesn't really work, I lead against differentiating between the there-is-a-pragma and there-is-not-a-pragma cases in some fundamental way.
>>
>>   2. I'm inclined to go with your choice (b) above because I think that
>> we should treat these concepts as orthogonal
> Agreed.
>
>> (to the extent that is reasonable: by design, we don't want to reassociate constrained operations, so that flag just might have on effect on those intrinsics). This lets the later optimization passes decide how to treat the various combinations of flags and intrinsics (just as with all other intrinsics that might be present).
> I think I agree, but this needs clarification. My view is that we don't want to reassociate constrained operations when `-fp-model=strict`. When `-fp-model=fast`, we should reassociate and do pretty much all the reasonably safe FMF transformations, with the caveat that I don't think NNAN and NINF make sense for any trap-safe mode. We may want to trap on those NaNs and Infs we'd optimize away.

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory