similar to: [LLVMdev] Representing -ffast-math at the IR level

Duncan, I have some issues with representing this as a single "fast" mode flag, which mostly boil down to the fact that this is a very C-centric view of the world. And, since C compilers are not generally known for their awesomeness on issues of numerics, I'm not sure that's a good idea. Having something called a "fast" or "relaxed" mode implies that it is

Hi Owen, > I have some issues with representing this as a single "fast" mode flag, it isn't a single flag, that's the whole point of using metadata. OK, right now there is only one option (the "accuracy"), true, but the intent is that others will be added, and the meaning of accuracy tightened, later. MDBuilder has a createFastFPMath method which is intended to

Hi Dmitry, > I'm not an expert in fp accuracy question, but I had quite a > few experience dealing with fp accuracy problems during compiler transformations. I agree that it's a minefield which is why I intend to proceed conservatively. > I think you have a step in the right direction, walking away from ULPs, which > are pretty useless for the purpose of describing allowed

Hi Duncan, I'm not an expert in fp accuracy question, but I had quite a few experience dealing with fp accuracy problems during compiler transformations. I think you have a step in the right direction, walking away from ULPs, which are pretty useless for the purpose of describing allowed fp optimizations IMHO. But using just "fast" keyword (or whatever else will be added in the

On Sat, Apr 14, 2012 at 11:44 PM, Duncan Sands <baldrick at free.fr> wrote: > > I think you have a step in the right direction, walking away from ULPs, >> which >> are pretty useless for the purpose of describing allowed fp optimizations >> IMHO. >> But using just "fast" keyword (or whatever else will be added in the >> future) is >> not

Here's a revised patch, plus patches showing how fpmath metadata could be turned on in clang and dragonegg (it seemed safest for the moment to condition on -ffast-math rather than on one of the flags implied by -ffast-math). Major changes: - The FPMathOperator class can no longer be used to change math settings, only to read them. Currently it can be queried for accuracy info. I split the

Thanks for the updates! Minor comments: + if (!Accuracy) + // If it's not a floating point number then it must be 'fast'. + return HUGE_VALF; Can we add an assert instead of a comment? It's just as documenting and will catch any goofs. + // If it's not a floating point number then it must be 'fast'. + return !isa<ConstantFP>(MD->getOperand(0));

Hi Dmitry, > The kinds of transforms I think can reasonably be done with the current > information are things like: x + 0.0 -> x; x / constant -> x * (1 / constant) if > constant and 1 / constant are normal (and not denormal) numbers. > > > The particular definition is not that important, as the fact that this > definition exists :) I.e. I think we need a

Hi Chandler, > Minor comments: > + if (!Accuracy) > + // If it's not a floating point number then it must be 'fast'. > + return HUGE_VALF; > > Can we add an assert instead of a comment? It's just as documenting and will > catch any goofs. Done. > > + // If it's not a floating point number then it must be 'fast'. > + return

Hi Dmitry, > That's possible (I already discussed this with Chandler), but in my opinion is > only worth doing if we see unreasonable increases in bitcode size in real code. > > > What is reasonable or not is defined not only by absolute numbers (0.8% or any > other number). Does it make sense to increase bitcode size by 1% if it's used > only by math library

On 14 April 2012 20:34, Duncan Sands <baldrick at free.fr> wrote: > the verifier checks that the accuracy operand is either a floating point > number (ConstantFP) or the keyword "fast".  If "Accuracy" is zero here > then that means it wasn't ConstantFP.  Thus it must have been the keyword > "fast". I think it's assuming too much. If I write

I realize that some of these thoughts apply equally to the prior !fpaccuracy metadata that's been around a while, but I hadn't looked at it closely until now. The !fpmath metadata violates the original spirit of metadata, which is that metadata is only supposed to exclude possible runtime conditions, rather than to introduce new possible runtime possibilities. The motivation for this is

On Sun, Apr 15, 2012 at 1:20 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 15 April 2012 09:07, Duncan Sands <baldrick at free.fr> wrote: > > Link-time optimization will sometimes result in "fast-math" functions > being > > inlined into non-fast math functions and vice-versa. This pretty much > > inevitably means that per-instruction

Hi Kevin, > 1. Most compiler and back-end control of floating point behavior appears to be > motivated by controlling the loss or gain of a few low bits of precision on > a whole module scale. In fact, these concerns are usually insignificant for > programmers of floating-point intensive applications. The input to most > floating point computations have far lower

Hi Renato, > I'm not sure about this: > > + if (!Accuracy) > + // If it's not a floating point number then it must be 'fast'. > + return getFastAccuracy(); > > Since you allow accuracies bigger than 1 in setFPAccuracy(), integers > should be treated as float. Or at least assert. the verifier checks that the accuracy operand is either a floating

Hi Duncan, I like the changes to IRBuilder and how the operator can't change it. Looks a lot safer (mistake-wise) and more convenient. This function won't to remove a previously set tag, which could be used by optimisations or inlining. + Instruction *AddFPMathTag(Instruction *I, MDNode *FPMathTag) const { + if (!FPMathTag) + FPMathTag = DefaultFPMathTag; + if (FPMathTag) +

On 15 April 2012 09:07, Duncan Sands <baldrick at free.fr> wrote: > Link-time optimization will sometimes result in "fast-math" functions being > inlined into non-fast math functions and vice-versa.  This pretty much > inevitably means that per-instruction fpmath options are required. I guess it would be user error if a strict function used the results of a non-strict

On Sun, Apr 15, 2012 at 1:02 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Dmitry, > > > The kinds of transforms I think can reasonably be done with the current >> information are things like: x + 0.0 -> x; x / constant -> x * (1 / >> constant) if >> constant and 1 / constant are normal (and not denormal) numbers. >> >> The

Duncan, Your effort to improve the control of floating point optimizations in LLVM is noble and commendable. I'd like to make two points that appear not to have been raised previously in the discussion of your proposal to date: 1) Most compiler and back-end control of floating point behavior appears to be motivated by controlling the loss or gain of a few low bits of precision

Hi Dan, > I realize that some of these thoughts apply equally to the > prior !fpaccuracy metadata that's been around a while, but I > hadn't looked at it closely until now. > > The !fpmath metadata violates the original spirit of > metadata, which is that metadata is only supposed to exclude > possible runtime conditions, rather than to introduce new > possible