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

[Hal Finkel]

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