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

[Sergey Dmitrouk]

Ping?

On Mon, Oct 13, 2014 at 08:52:25AM -0700, Hal Finkel wrote:
> ----- Original Message -----
> > From: "Sergey Dmitrouk" <sdmitrouk at accesssoftek.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: "llvm-commits" <llvm-commits at cs.uiuc.edu>
> > Sent: Monday, October 13, 2014 2:27:01 AM
> > Subject: Re: [PATCH] Flag to enable IEEE-754 friendly FP optimizations
> > 
> > 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.
> 
> Well, if you're just calling some function that might set a exception flag, and then testing for it later on a system where the math functions are not marked as readnone, then you'd still have the needed dependencies in your test cases. The problem comes up when you have the functions that test the environment state called from the function that might be setting the flags.
> 
> > 
> > > 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.
> 
> Ah, interesting. Perhaps Steve or Owen (cc'd) have thoughts on what we might do about this, and whether it is worth going after this case.
> 
>  -Hal
> 
> > 
> > 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
> > 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory