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

James Molloy james at jamesmolloy.co.uk
Mon Oct 13 00:53:20 PDT 2014


Hi Sergey,

Since this is a very specific use case, where exceptions are trying to be
triggered using strange constructs, might it not be simpler to introduce a
simple builtin that musl could call instead?

Cheers,

James

On 13 October 2014 08:27, Sergey Dmitrouk <sdmitrouk at accesssoftek.com>
wrote:

> Hi Hal,
>
> > And it is really (2) that is the larger problem: LLVM always might
> reorder the
> > FP operation you're trying to test and the function you're using to test
> the
> > FP exception state after the operation.
>
> I didn't realize this can happen in general case, and it didn't occur in
> my use case.
>
> > I'd like to understand exactly how you'd like to use this functionality.
>
> I'm compiling musl-libc ([0]) with Clang.  Its libm implementation (not
> sure how this is done in other libc implementation) relies on compiler to
> behave according to C standard (including Annex F.8).  FP exceptions are
> generated with expressions such as "0.0/0.0", "1.0/0.0", "-1.0/0.0" or
> multiplications of huge/tiny values.  Folding FP operations at compile
> time kills libm's ability to raise exceptions in quite a lot of cases.
>
> Thanks,
> Sergey
>
> 0: http://www.musl-libc.org/
>
> On Thu, Oct 09, 2014 at 08:09:59PM -0700, Hal Finkel wrote:
> > Hi Sergey,
> >
> > Thanks for posting these. Just so we can better understand the boundary
> conditions here, can you please explain your use case? I ask because my
> understand is that there are really two parts to this problem:
> >
> >  1. We sometimes "constant fold" away FP ops that might have set
> exception flags (overflow, underflow, etc.) -- Your patches address this.
> >
> >  2. We have no way of expressing control dependencies on FP operations
> in LLVM on function calls that might manipulation the FP environment or
> read the exception state.
> >
> > And it is really (2) that is the larger problem: LLVM always might
> reorder the FP operation you're trying to test and the function you're
> using to test the FP exception state after the operation. But this assumes
> that these function calls are also in the IR (perhaps they're not in your
> case), so I'd like to understand exactly how you'd like to use this
> functionality.
> >
> > Thanks again,
> > Hal
> >
> > ----- Original Message -----
> > > From: "Sergey Dmitrouk" <sdmitrouk at accesssoftek.com>
> > > To: "llvm-commits" <llvm-commits at cs.uiuc.edu>
> > > Sent: Friday, October 3, 2014 12:33:25 PM
> > > Subject: [PATCH] Flag to enable IEEE-754 friendly FP optimizations
> > >
> > > Hello,
> > >
> > > this is continuation of LLVM-dev's thread "More careful treatment of
> > > floating point exceptions".  There wasn't much discussion there, so I
> > > just repeat updated version of the main part of text below.
> > >
> > > Currently, LLVM optimizes some floating point operations by replacing
> > > them with result evaluated at compile-time even if their execution at
> > > run-time would cause floating point exceptions.  I'm trying to
> > > introduce
> > > a flag (off by default) that would disable such optimizations.  This
> > > isn't trivial as related code is located in different parts of LLVM,
> > > so
> > > don't expect attached patches to be ready to be applied, they are
> > > rather
> > > something that works and require review from people that have much
> > > more
> > > experience with LLVM codebase than me.
> > >
> > > There are two sources of the flag (well three, if command-line option
> > > is
> > > counted): field of TargetOptions and function attribute.  The later
> > > one
> > > is for InstCombine and similar passes, which do not have references
> > > to
> > > code generation option.
> > >
> > > Please find the attached patches.  Is there a better way to implement
> > > patch
> > > number 0004?  Would it make sense to mark IR instructions instead or
> > > maybe creating some special forms for them?  The issue here is caused
> > > by an
> > > assumption that floating point operations are target independent,
> > > which
> > > doesn't hold if one wants an option to switch between optimized
> > > floating
> > > point operations and IEEE conformance.  If there is another way to
> > > communicate state of the option to "target-independent" IR
> > > optimizations,
> > > which could replace adding additional argument to a bunch of
> > > functions, I
> > > would rather switched to it.
> > >
> > > Thanks,
> > > Sergey
> > >
> > > P.S. Also thinking about "PreserveFPExceptions" as an alternative
> > > name.
> > >
> > > _______________________________________________
> > > llvm-commits mailing list
> > > llvm-commits at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> > >
> >
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141013/14c2c7d1/attachment.html>


More information about the llvm-commits mailing list