[PATCH] Flag to enable IEEE-754 friendly FP optimizations
Sergey Dmitrouk
sdmitrouk at accesssoftek.com
Mon Oct 13 01:20:20 PDT 2014
Hi James,
I wouldn't call this "very specific case" as it seems to be the reason why
support of C99+ and C++11+ isn't complete with regard to floating point
operations. The only way to implement "#pragma STDC FENV_ACCESS ON" now is
probably to use inline assembly in the front-end.
I also tried to fix this in musl initially, but was convinced that it's
more of a compiler issue.
Regards,
Sergey
[0]: https://github.com/rust-lang/rust/issues/10186
On Mon, Oct 13, 2014 at 12:53:20AM -0700, James Molloy wrote:
> 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.A 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).A 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.A 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:
> >
> >A 1. We sometimes "constant fold" away FP ops that might have set
> exception flags (overflow, underflow, etc.) -- Your patches address
> this.
> >
> >A 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".A 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.A I'm trying to
> > > introduce
> > > a flag (off by default) that would disable such optimizations.A
> 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.A The later
> > > one
> > > is for InstCombine and similar passes, which do not have references
> > > to
> > > code generation option.
> > >
> > > Please find the attached patches.A Is there a better way to
> implement
> > > patch
> > > number 0004?A Would it make sense to mark IR instructions instead
> or
> > > maybe creating some special forms for them?A 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.A 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
More information about the llvm-commits
mailing list