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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Morse via llvm-dev

Hi all,

 

A question came up in a code review (https://reviews.llvm.org/D72820) about whether or not to allow fast-math flags to be applied to constrained floating point intrinsics (http://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics). This has come up several times before, but I don’t think we’ve ever made a decision about it.

 

By default, the optimizer assumes that floating point operations have no side effects and use the default rounding mode (round to nearest, ties to even). The constrained intrinsics are meant to prevent the optimizer from making these assumptions when the user wants to access the floating point environment -- to change the rounding mode, to check floating point status bits, or to unmask floating point exceptions. The intrinsics have an argument that either specify a rounding mode that may be assumed or specify that the rounding mode is unknown (this argument is omitted if it doesn’t apply to the operation) and an argument to specify whether the user wants precise exception semantics to be preserved, wants to prevent syntactically spurious exceptions from being raised, or doesn’t care about floating point exceptions.

 

Because the constrained mode can be localized to a sub-region within a function, we also need to support the case where a constrained intrinsic is used but the default behavior (default rounding mode, exceptions ignored) is used. For this reason, I think our IR definition must allow fast math flags to be applied to constrained intrinsics. That makes this primarily a question about what combinations should be permitted by front ends and how constructs like pragmas should affect the various states. For example, I might have source code like this:

 

-=-=-=-=-=-=-=-=

 

double doSomethingVague(double X, double Y, double Z) {

  // Some operation that doesn’t need to be precise.

  if (X/Y > SomeThreshold)

    return doSomethingPrecise(X, Y);

  else

    return Z;

}

 

#pragma STDC FENV_ACCESS ON

double doSomethingPrecise(double X, double Y) {

  int SaveRM = fegetround();

  fesetround(FE_DOWNWARD);

  feclearexcept(FE_ALL_EXCEPT);

  double Temp = X * Y + Z;

  if (fetestexcept(FE_ALL_EXCEPT))

    std::cerr << “Something happened.\n”;

  fesetround(SaveRM);

  return Temp;

}

 

-=-=-=-=-=-=-=-=

 

Now suppose I compile that with “-O2 -ffp-contract=fast”. We will need to generate constrained intrinsics for the X*Y+Z expression in doSomethingPrecise. The question is, should clang (a) generate a constrained version of the llvm.fmuladd instrinsic, (b) generate separate constrained.fmul and constrained.fadd instrinsics with the contract fast math flag set, or (c) generate separate constrained.fmul and constrained.fadd instrinsics with no fast math flag? I would argue for (b), because I think it’s reasonable for a user who cares about precision and FP exceptions to still want FMA, which theoretically is more precise. I think not (a) because clang doesn’t usually generate the fmuladd intrinsic with -ffp-contract=fast. On the other hand, if the code also contained an FP_CONTRACT pragma around doSomethingPrecise() I think clang should do (a).

 

Supporting the FP_CONTRACT case is the point of the D72820 patch.

 

But let’s make this more interesting. Suppose I compile with “-O2 -fp-model=strict -ffp-contract=fast -fno-honor-nans -fno-honor-infinities -fno-signed-zeros” instead and the code does not contain the FENV_ACCESS pragma (I’ll get back to that). Should the nnan, ninf, and nsz fast math flags be applied to the constrained intrinsics? I lean toward “yes”. The way I see it, these command line options are a way for the user to tell the compiler that their data will not contain NaNs or infinities and that their algorithms do not depend on the sign of zero. These flags enable us to make some optimizations that will not affect rounding or exception semantics as long as the data is as the user claimed. This will be particularly useful for the strict exception semantics because there are cases where we have to execute additional instructions just to preserve the exception semantics in the case where one of the operands is a NaN. If the user knows that will never happen, we can produce better code.

 

Now back to the reason I wanted to consider that without the pragma. Consider my code above with the pragma again, now imagine I compile it with “-O2 -fp-model=fast”. In this case, the pragma almost certainly intends to remove some fast math flags. For instance, I don’t think it makes sense to say you care about rounding mode but want to allow reassociation (because reassociation has a much bigger potential to change results than rounding mode). The flags discussed above could make sense, but we have no clear way to know what the user intended, so I think in this case we must clear all the fast math flags. This kind of conflicts with what I said about the contract flag above. I obviously have mixed feelings about that. In the presence of a pragma, we should probably block the contract flag too, but I don’t like having to do that for that specific case.

 

There’s my opinion. I’d like to hear what others think.

 

Thanks,

Andy


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Morse via llvm-dev


On 1/17/20 6:30 PM, Kaylor, Andrew wrote:

Hi all,

 

A question came up in a code review (https://reviews.llvm.org/D72820) about whether or not to allow fast-math flags to be applied to constrained floating point intrinsics (http://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics). This has come up several times before, but I don’t think we’ve ever made a decision about it.

 

By default, the optimizer assumes that floating point operations have no side effects and use the default rounding mode (round to nearest, ties to even). The constrained intrinsics are meant to prevent the optimizer from making these assumptions when the user wants to access the floating point environment -- to change the rounding mode, to check floating point status bits, or to unmask floating point exceptions. The intrinsics have an argument that either specify a rounding mode that may be assumed or specify that the rounding mode is unknown (this argument is omitted if it doesn’t apply to the operation) and an argument to specify whether the user wants precise exception semantics to be preserved, wants to prevent syntactically spurious exceptions from being raised, or doesn’t care about floating point exceptions.

 

Because the constrained mode can be localized to a sub-region within a function, we also need to support the case where a constrained intrinsic is used but the default behavior (default rounding mode, exceptions ignored) is used. For this reason, I think our IR definition must allow fast math flags to be applied to constrained intrinsics. That makes this primarily a question about what combinations should be permitted by front ends and how constructs like pragmas should affect the various states. For example, I might have source code like this:

 

-=-=-=-=-=-=-=-=

 

double doSomethingVague(double X, double Y, double Z) {

  // Some operation that doesn’t need to be precise.

  if (X/Y > SomeThreshold)

    return doSomethingPrecise(X, Y);

  else

    return Z;

}

 

#pragma STDC FENV_ACCESS ON

double doSomethingPrecise(double X, double Y) {

  int SaveRM = fegetround();

  fesetround(FE_DOWNWARD);

  feclearexcept(FE_ALL_EXCEPT);

  double Temp = X * Y + Z;

  if (fetestexcept(FE_ALL_EXCEPT))

    std::cerr << “Something happened.\n”;

  fesetround(SaveRM);

  return Temp;

}

 

-=-=-=-=-=-=-=-=

 

Now suppose I compile that with “-O2 -ffp-contract=fast”. We will need to generate constrained intrinsics for the X*Y+Z expression in doSomethingPrecise. The question is, should clang (a) generate a constrained version of the llvm.fmuladd instrinsic, (b) generate separate constrained.fmul and constrained.fadd instrinsics with the contract fast math flag set, or (c) generate separate constrained.fmul and constrained.fadd instrinsics with no fast math flag? I would argue for (b), because I think it’s reasonable for a user who cares about precision and FP exceptions to still want FMA, which theoretically is more precise. I think not (a) because clang doesn’t usually generate the fmuladd intrinsic with -ffp-contract=fast. On the other hand, if the code also contained an FP_CONTRACT pragma around doSomethingPrecise() I think clang should do (a).

 

Supporting the FP_CONTRACT case is the point of the D72820 patch.

 

But let’s make this more interesting. Suppose I compile with “-O2 -fp-model=strict -ffp-contract=fast -fno-honor-nans -fno-honor-infinities -fno-signed-zeros” instead and the code does not contain the FENV_ACCESS pragma (I’ll get back to that). Should the nnan, ninf, and nsz fast math flags be applied to the constrained intrinsics? I lean toward “yes”. The way I see it, these command line options are a way for the user to tell the compiler that their data will not contain NaNs or infinities and that their algorithms do not depend on the sign of zero. These flags enable us to make some optimizations that will not affect rounding or exception semantics as long as the data is as the user claimed. This will be particularly useful for the strict exception semantics because there are cases where we have to execute additional instructions just to preserve the exception semantics in the case where one of the operands is a NaN. If the user knows that will never happen, we can produce better code.

 

Now back to the reason I wanted to consider that without the pragma. Consider my code above with the pragma again, now imagine I compile it with “-O2 -fp-model=fast”. In this case, the pragma almost certainly intends to remove some fast math flags. For instance, I don’t think it makes sense to say you care about rounding mode but want to allow reassociation (because reassociation has a much bigger potential to change results than rounding mode). The flags discussed above could make sense, but we have no clear way to know what the user intended, so I think in this case we must clear all the fast math flags. This kind of conflicts with what I said about the contract flag above. I obviously have mixed feelings about that. In the presence of a pragma, we should probably block the contract flag too, but I don’t like having to do that for that specific case.

 

There’s my opinion. I’d like to hear what others think.


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 (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).

 3. Your examples with the various fast-math flags speak to a granularity mismatch that we may wish to resolve: pragmas allow for local control, but the command-line parameters provide global settings, and we just have that for fast-math flags. I'd be very-much in favor of pragmas to allow local control of those too. There have been plenty of times that I've wanted that for fast-math flags.

 -Hal


 

Thanks,

Andy

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

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Morse via llvm-dev
On Fri, Jan 17, 2020 at 8:09 PM Finkel, Hal J. <[hidden email]> 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.
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Morse via llvm-dev
One of the viewpoints on the constrained intrinsics is that it is a way to represent floating point environment. In this case they are just variants of corresponding IR nodes and in theory we could use the constrained intrinsics everywhere instead of the regular nodes. From this viewpoint it make sense to keep symmetry between constrained intrinsics and corresponding regular IR nodes.

So for the first question the variant `a` (generate a constrained version of the llvm.fmuladd instrinsic) looks preferable. Additional flags that specify the way compiler should treat this node (like fast math flags) should be applied to constrained intrinsics in the same extent as to the non-constrained counterparts. Particular combination of a node and additional flags may be treated differently for constrained intrinsics depending on its semantics.

This symmetry could help us in implementing full-fledged support of the constrained intrinsics in transformation - they would share the same code path with corresponding non-constrained nodes. 

Thanks,
--Serge


On Sat, Jan 18, 2020 at 10:25 PM Cameron McInally <[hidden email]> wrote:
On Fri, Jan 17, 2020 at 8:09 PM Finkel, Hal J. <[hidden email]> 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.

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Morse via llvm-dev

Serge Pavlov <[hidden email]> wrote on 20.01.2020 09:12:55:

> One of the viewpoints on the constrained intrinsics is that it is a
> way to represent floating point environment. In this case they are
> just variants of corresponding IR nodes and in theory we could use
> the constrained intrinsics everywhere instead of the regular nodes.
> From this viewpoint it make sense to keep symmetry between
> constrained intrinsics and corresponding regular IR nodes.

Agreed with this.
 
> So for the first question the variant `a` (generate a constrained
> version of the llvm.fmuladd instrinsic) looks preferable.


But not with this.  Note that in Andrew's example we are operating
under -ffp-contract=fast, in which case clang never emits fmuladd,
so it shouldn't in the constrained case either.  Instead, it will
emit fmul/fadd nodes with the contract FMF set, so in constrained
mode it should emit constrained fmul/fadd with the contract FMF set.
(This was Andrew's variant (b).)

fmuladd is only emitted in the -ffp-contract=on case, which is
intended to allow contractions only within a single source statement.
Since the LLVM back-end no longer knows the boundaries of source
statemtents, this requires help from clang; this is why clang will
emit fmuladd in those cases where the mul and add originate from
within the same source statement.

To fully map all these cases onto constrained intrinsics, we need
both to allow contract (and other) FMFs on constrained intrinsics
*and* allow a constrained fmuladd.

Bye,
Ulrich


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Reply | Threaded
Open this post in threaded view
|

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

Jeremy Morse via llvm-dev
In reply to this post by Jeremy Morse via llvm-dev
> 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.


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 <[hidden email]>
Sent: Saturday, January 18, 2020 7:25 AM
To: Finkel, Hal J. <[hidden email]>
Cc: Kaylor, Andrew <[hidden email]>; LLVM Developers Mailing List <[hidden email]>; [hidden email]; Kevin Neal <[hidden email]>; Ulrich Weigand ([hidden email]) <[hidden email]>; Wang, Pengfei <[hidden email]>; John McCall ([hidden email]) <[hidden email]>; Arsenault, Matthew <[hidden email]>; Serge Pavlov <[hidden email]>; Blower, Melanie I <[hidden email]>; Sanjay Patel <[hidden email]>; Stephen Canon <[hidden email]>
Subject: Re: Combining fast math flags with constrained intrinsics

On Fri, Jan 17, 2020 at 8:09 PM Finkel, Hal J. <[hidden email]> 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.
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Morse 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 <[hidden email]>
> Sent: Saturday, January 18, 2020 7:25 AM
> To: Finkel, Hal J. <[hidden email]>
> Cc: Kaylor, Andrew <[hidden email]>; LLVM Developers Mailing List <[hidden email]>; [hidden email]; Kevin Neal <[hidden email]>; Ulrich Weigand ([hidden email]) <[hidden email]>; Wang, Pengfei <[hidden email]>; John McCall ([hidden email]) <[hidden email]>; Arsenault, Matthew <[hidden email]>; Serge Pavlov <[hidden email]>; Blower, Melanie I <[hidden email]>; Sanjay Patel <[hidden email]>; Stephen Canon <[hidden email]>
> Subject: Re: Combining fast math flags with constrained intrinsics
>
> On Fri, Jan 17, 2020 at 8:09 PM Finkel, Hal J. <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Morse via llvm-dev
In reply to this post by Jeremy Morse via llvm-dev
On 21/01/20 17:59, Kaylor, Andrew via llvm-dev wrote:
> 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.

As a user (I did a load of programming ages ago calculating distances
from lats and longs), I heartily second having it documented!

I've known for ages that (some) computers can handle infinity and stuff,
and if I'd known that the compiler/language got it right it would have
made my life much simpler. As it was I had to special-case anywhere two
lats or longs were equal, whereas the maths just said "a divide by zero
will promptly be followed by a divide by infinity so it all cancels out".

Being able to rely on the compiler would have been so much nicer.

Cheers,
Wol
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Morse via llvm-dev
In reply to this post by Jeremy Morse via llvm-dev
On Tue, Jan 21, 2020 at 1:08 PM Finkel, Hal J. <[hidden email]> 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.
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev