[LLVMdev] More careful treatment of floating point exceptions

[Hal Finkel]

----- Original Message -----
> From: "Sergey Dmitrouk" <sdmitrouk at accesssoftek.com>
> To: "Owen Anderson" <resistor at mac.com>
> Cc: "LLVMdev" <llvmdev at cs.uiuc.edu>
> Sent: Thursday, September 25, 2014 4:47:52 AM
> Subject: Re: [LLVMdev] More careful treatment of floating point exceptions
> 
> Hi again,
> 
> It's partially done.  My concern is that it won't be accepted as is
> because of adding the flag parameter in a lot of places.  I'd like to
> show
> what it looks like (here, not on llvm-commit yet),  maybe someone
> could
> suggest a better way.

Hi Sergey,

Thanks for working on this!

I definitely recommend moving this thread to llvm-commits; that's where we do patch review (even if that review recommends an entirely different direction).

For Clang, you'll likely want a new flag in LangOptions.

 -Hal

> 
> There are two sources of the flag: field of TargetOptions and
> function
> attribute.  I had to add the later one for InstCombine pass.  Still
> it's
> not enough for one place in Clang, where I can't get to code
> generation
> attribute.
> 
> Please find the attached patches.  Is there a better way to implement
> patch
> number 0006?  Would it make sense to mark IR instructions instead or
> maybe create 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.
> 
> Basically, I'm looking for another way to communicate state of the
> option
> to "target-independent" IR optimizations, which could replace adding
> additional argument to a bunch of functions.
> 
> Thanks,
> Sergey
> 
> On Fri, Sep 19, 2014 at 01:07:17PM -0700, Owen Anderson wrote:
> > Both forms are useful.  There are some platforms (some GPUs and
> > accelerators) that simply do not support floating point
> > exceptions, and there are other platforms (most CPUs) that can
> > suppose precise floating point exceptions, but where we generally
> > don’t want to for performance reasons.
> > 
> > I suspect there’s a tripartite breakdown at play here:
> > 	(1) Use cases where we don’t care about exceptions at all, e.g.
> > 	compiling GLSL programs for a GPU.
> > 	(2) Use cases where we want strict IEEE conformance.
> > 	(3) Use cases where we want to support a reasonable degree of
> > 	conformance (e.g., still getting a division by zero exception),
> > 	but without all the performance constrains of (2).  This would be
> > 	the default for normal clang invocations.
> > 
> > —Owen
> > 
> > > On Sep 19, 2014, at 12:59 PM, Sergey Dmitrouk
> > > <sdmitrouk at accesssoftek.com> wrote:
> > > 
> > > Hi Sanjay,
> > > 
> > > Thanks, I saw this flag and it's definitely should be considered,
> > > but
> > > it appeared to me to be static characteristic of target platform.
> > >  I'm
> > > not sure how appropriate it would be to change its value from a
> > > front-end.
> > > It says "Has", while optional flag would rather say "Uses"
> > > meaning that
> > > implementation cares about floating point exceptions.
> > > 
> > > Regards,
> > > Sergey
> > > 
> > > On Fri, Sep 19, 2014 at 12:01:07PM -0700, Sanjay Patel wrote:
> > >>   Hi Sergey -
> > >> 
> > >>   Does this solve part of the problem?
> > >>   http://llvm.org/viewvc/llvm-project?view=revision&revision=215222
> > >>   On Fri, Sep 19, 2014 at 9:12 AM, Sergey Dmitrouk
> > >>   <sdmitrouk at accesssoftek.com> wrote:
> > >> 
> > >>     Hi,
> > >> 
> > >>     I'd like to make code emitted by LLVM that includes floating
> > >>     point
> > >>     operations which raise FP exceptions behave closer to what
> > >>     is defined by
> > >>     IEEE754 standard.A  I'm not going to "fix everything", just
> > >>     incorrect
> > >>     behaviour I faced so far.
> > >> 
> > >>     Most of troubles regarding FP exceptions are caused by
> > >>     optimizations, so
> > >>     there should be a flag to disable/block them if one wants to
> > >>     get better
> > >>     code in a sense of its IEEE754 conformance.A  I couldn't
> > >>     find an
> > >>     existing
> > >>     flag for this and would like to introduce one.A  I guess it
> > >>     should be
> > >>     added to llvm::TargetOptions (e.g. "IEEE754FPE"), then
> > >>     -std=c99 or
> > >>     separate option could enable it from front-end (Clang in
> > >>     this case).
> > >> 
> > >>     I'm doing this for ARM platform and the flag should be
> > >>     reachable from
> > >>     all these places in LLVM:
> > >> 
> > >>     A - lib/Analysis/ValueTracking.cpp
> > >>     A - lib/CodeGen/SelectionDAG/SelectionDAG.cpp
> > >>     A - lib/IR/ConstantFold.cpp
> > >>     A - lib/Target/ARM/ARMFastISel.cpp
> > >>     A - lib/Target/ARM/ARMISelLowering.cpp
> > >>     A - lib/Target/ARM/ARMInstrVFP.td (through predicates)
> > >>     A - lib/Target/ARM/ARMRegisterInfo.td (through predicates)
> > >> 
> > >>     and in Clang:
> > >> 
> > >>     A - lib/AST/ExprConstant.cpp
> > >> 
> > >>     Did I get it right and there is no such flag so far?A  Does
> > >>     what I'm
> > >>     suggesting sounds reasonable?
> > >> 
> > >>     Thanks,
> > >>     Sergey
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

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