[PATCH] Flag to enable IEEE-754 friendly FP optimizations
mehdi.amini at apple.com
Mon Jan 12 11:58:25 PST 2015
Digging through the history. It seems that to avoid folding that triggers invalid results, ConstantFoldFP() is checking for floating point exceptions and errno.
The test use to be:
if (errno != 0 ||
fetestexcept(FE_DIVBYZERO | FE_UNDERFLOW | FE_OVERFLOW | FE_INVALID))
However as the comment says, "some host libms have known errors raising exceptions.” and this condition could fails.
Now if we don’t care about floating point exception, we should be able to fold anyway.
It means that ConstantFoldFP() should also take KeepExceptions into account.
> On Jan 12, 2015, at 11:45 AM, Sergey Dmitrouk <sdmitrouk at accesssoftek.com> wrote:
> Hello Mehdi,
> It will require passing the flag along with TargetLibraryInfo, but it
> should be possible.
> I'm not sure I completely understand what the comment says. I'd turn it
> into something like
> if (KeepExceptions &&
> (Op->getValueAPF().isNaN() || Op->getValueAPF().isInfinity()))
> return nullptr;
> Which means that if we don't care about floating-point exceptions at
> run-time, we also don't care if host libm raises exceptions properly.
> Is this correct? If yes, there is a drawback that default behaviour
> will change for "some host libms", which is undesirable. Please correct
> me if I misunderstood you.
> On Mon, Jan 12, 2015 at 09:43:09AM -0800, Mehdi Amini wrote:
>> Oh great some flags to help with floating point corner cases :)
>> A question: lib/Analysis/ConstantFolding.cpp contains this code that prevent folding NaN/Inf in InstCombine:
>> /// We only fold functions with finite arguments. Folding NaN and inf is
>> /// likely to be aborted with an exception anyway, and some host libms
>> /// have known errors raising exceptions.
>> if (Op->getValueAPF().isNaN() || Op->getValueAPF().isInfinity())
>> return nullptr;
>> Can this be tied to KeepExceptions?
>>> On Jan 12, 2015, at 12:21 AM, Sergey Dmitrouk <sdmitrouk at accesssoftek.com> wrote:
>>> On Mon, Dec 22, 2014 at 11:36:10AM +0200, Sergey Dmitrouk wrote:
>>>> Hello Hal,
>>>> it took me some time to change the way it works, but now new changes also
>>>> cover some cases missed in the previous version.
>>>> After thinking a bit more I introduced two separate flags for exceptions
>>>> and rounding, as you suggested. At the moment rounding flag just
>>>> disables folding, I'm not sure how to actually check that result of
>>>> operation doesn't depend on rounding mode. This prevents early
>>>> optimization for something like "1.0 + 2.0", so might need adjustments
>>>> if there is a way to check whether rounding is important for particular
>>>> Using fast-math flags instead of function attributes didn't remove that
>>>> much flags as they are not used in code related to constant expression
>>>> folding. In fact, I had to add one more "Strict" argument to be able to
>>>> prevent conversion to constant expressions, which results in losing
>>>> fast-math flags.
>>>> Please find updated set of patches in the attachment.
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
More information about the llvm-commits