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. 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. I couldn't find an existing
flag for this and would like to introduce one. 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:
- lib/Analysis/ValueTracking.cpp
- lib/CodeGen/SelectionDAG/SelectionDAG.cpp
- lib/IR/ConstantFold.cpp
- lib/Target/ARM/ARMFastISel.cpp
- lib/Target/ARM/ARMISelLowering.cpp
- lib/Target/ARM/ARMInstrVFP.td (through predicates)
- lib/Target/ARM/ARMRegisterInfo.td (through predicates)
and in Clang:
- lib/AST/ExprConstant.cpp
Did I get it right and there is no such flag so far? Does what I'm
suggesting sounds reasonable?
Thanks,
Sergey
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
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
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.
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
0001-Do-not-emit-intermediate-register-for-zero-FP-imm.patch (1.81 KB)
0002-Double-check-for-constant-expression-domination.patch (770 Bytes)
0003-Add-HonorFPExceptions-flag-to-TargetOptions.patch (1.5 KB)
0004-Consider-HonorFPExceptions-flag-in-SelectionDAG.patch (3.94 KB)
0005-Skip-constant-folding-to-preserve-FP-exceptions.patch (8.8 KB)
0006-Pass-HonorFPExceptions-flag-around.patch (15.2 KB)
0007-Use-honor-fp-exceptions-function-attribute.patch (6.09 KB)
From: "Sergey Dmitrouk" <sdmitrouk@accesssoftek.com>
To: "Owen Anderson" <resistor@mac.com>
Cc: "LLVMdev" <llvmdev@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
Hi Hal,
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).
OK, I'll do that tomorrow with slightly updated patches.
For Clang, you'll likely want a new flag in LangOptions.
Thanks, this means I found the correct place at the end. Already added
new flag to LangOptions after looking around a bit more (its Doxygen
documentation is broken because of macros, which misleads).
Thanks,
Sergey