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

[Hal Finkel]

----- Original Message -----
> From: "Stephen Canon" <scanon at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Sergey Dmitrouk" <sdmitrouk at accesssoftek.com>, "llvm-commits" <llvm-commits at cs.uiuc.edu>, "Owen Anderson"
> <owen at apple.com>
> Sent: Friday, October 24, 2014 11:13:10 AM
> Subject: Re: [PATCH] Flag to enable IEEE-754 friendly FP optimizations
> 
> As a necessary piece of building support for FENV_ACCESS, yes, I
> think this is worth pursuing.  Note, however, that actually
> providing full FENV_ACCESS support is likely to be a significant
> undertaking, and I expect that the pieces that go into it are
> basically useless until all of them are in place.  That’s not to say
> that it isn’t worth doing, just that it’s a big thankless job.

Steve, so long as you're willing to serve as the expert reviewer here, I'm happy to help move this forward as well. We should, however, probably have a plan for the rest of it. Maybe this is as simple as: when FP exceptions are enabled, we treat all FP operations as if they might write to memory (except that AA confirms that they don't actually alias with any address in particular, but we say nothing about function calls). What do you think?

 -Hal

> 
> – Steve
> 
> > On Oct 13, 2014, at 11:52 AM, Hal Finkel <hfinkel at anl.gov> 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
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory