[PATCH] Flag to enable IEEE-754 friendly FP optimizations

Sergey Dmitrouk sdmitrouk at accesssoftek.com
Mon Jan 12 12:14:29 PST 2015


I'll add checks of the flag there.  Thanks for pointing this out.

Best regards,
Sergey

On Mon, Jan 12, 2015 at 11:58:25AM -0800, Mehdi Amini wrote:
> 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.
>
> Best,
>
> Mehdi
>
> > 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.
> >
> > Regards,
> > Sergey
> >
> > On Mon, Jan 12, 2015 at 09:43:09AM -0800, Mehdi Amini wrote:
> >> Hi,
> >>
> >> 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?
> >>
> >> Thanks,
> >>
> >> Mehdi
> >>
> >>> On Jan 12, 2015, at 12:21 AM, Sergey Dmitrouk <sdmitrouk at accesssoftek.com> wrote:
> >>>
> >>> Ping.
> >>>
> >>> 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
> >>>> operation.
> >>>>
> >>>> 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.
> >>>>
> >>>> Thanks,
> >>>> Sergey
> >>> _______________________________________________
> >>> llvm-commits mailing list
> >>> llvm-commits at cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list