search for: fpmath

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 that optimizers that ignore metadata should always be safe. With !fpmath, theore...

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 runtime possibilities. The motivation for this is > that optimizers that ignore metadata should always be safe....

> It also has the problem that there's nothing preventing a > pass like GVN from merging a !fpmath-decorated operation with an > undecorated operation, and nothing requiring it to strip > the !fpmath tag when it does so. (This is a general problem > with LLVM metadata semantics.) Can it? My impression from the last discussion on alias analysis is that a pass can drop metadata it doesn&...

...at 11:50 PM, Duncan Sands <baldrick at free.fr> wrote: > 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 runtime possibilities. The motivation for this is >> that optimizers that ignore metadata should...

The attached patch is a first attempt at representing "-ffast-math" at the IR level, in fact on individual floating point instructions (fadd, fsub etc). It is done using metadata. We already have a "fpmath" metadata type which can be used to signal that reduced precision is OK for a floating point operation, eg %z = fmul float %x, %y, !fpmath !0 ... !0 = metadata !{double 2.5} indicates that the multiplication can be done in any way that doesn't introduce more than 2.5 ULPs of e...

Hi Dan, > 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. This was already violated by objc-specific metadata and if I get Chris right - this is the i...

...10:28 PM, Duncan Sands <baldrick at free.fr> wrote: > The attached patch is a first attempt at representing "-ffast-math" at the > IR > level, in fact on individual floating point instructions (fadd, fsub etc). > It > is done using metadata. We already have a "fpmath" metadata type which > can be > used to signal that reduced precision is OK for a floating point > operation, eg > > %z = fmul float %x, %y, !fpmath !0 > ... > !0 = metadata !{double 2.5} > > indicates that the multiplication can be done in any way that doesn...

On Tue, 17 Apr 2012 08:38:18 -0400 Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > It also has the problem that there's nothing preventing a > > pass like GVN from merging a !fpmath-decorated operation with an > > undecorated operation, and nothing requiring it to strip > > the !fpmath tag when it does so. (This is a general problem > > with LLVM metadata semantics.) > > Can it? My impression from the last discussion on alias analysis is > that a pa...

...> <mailto:baldrick at free.fr>> wrote: > > The attached patch is a first attempt at representing "-ffast-math" at the IR > level, in fact on individual floating point instructions (fadd, fsub etc). It > is done using metadata. We already have a "fpmath" metadata type which can be > used to signal that reduced precision is OK for a floating point operation, eg > > %z = fmul float %x, %y, !fpmath !0 > ... > !0 = metadata !{double 2.5} > > indicates that the multiplication can be done in any way...

...2012, at 11:28 AM, Duncan Sands <baldrick at free.fr> wrote: > The attached patch is a first attempt at representing "-ffast-math" at the IR > level, in fact on individual floating point instructions (fadd, fsub etc). It > is done using metadata. We already have a "fpmath" metadata type which can be > used to signal that reduced precision is OK for a floating point operation, eg > > %z = fmul float %x, %y, !fpmath !0 > ... > !0 = metadata !{double 2.5} > > indicates that the multiplication can be done in any way that doesn't intr...

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...

2012/4/17 Hal Finkel <hfinkel at anl.gov>: > In reality, metadata might want to have merging rules and a defined API > so that metadata merging can be used by a number of passes > (vectorization will need this too). For example, merging fp-accuracy > data should choose the more-stringent bound, but not really be removed > all together. +1! The original intent of metadata was

On Tue, 17 Apr 2012 11:53:25 -0700 Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Apr 17, 2012 at 11:29 AM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: > >> The point isn't whether it's a good idea to discard FP precision > >> data (or vectorization data, or debug data), but rather whether IR > >> transformations are

> For a transformation pass, should we do this only if the pass actually > changed something? In the pass manager? That is interesting. What I had in mind was just changing the passes to only copy the metadata info they know about. The problem is that in examples like the one Dan created. The pass would have to delete metadata in an instruction it reasoned about but didn't otherwise

> The point isn't whether it's a good idea to discard FP precision data > (or vectorization data, or debug data), but rather whether IR > transformations are allowed to treat a meta-data annotated instruction > as having the same semantics as an unannotated instruction.  If > transformation passes which aren't metadata aware aren't allowed to > reason about an

...ee.fr>> wrote: >> >> The attached patch is a first attempt at representing "-ffast-math" at >> the IR >> level, in fact on individual floating point instructions (fadd, fsub >> etc). It >> is done using metadata. We already have a "fpmath" metadata type >> which can be >> used to signal that reduced precision is OK for a floating point >> operation, eg >> >> %z = fmul float %x, %y, !fpmath !0 >> ... >> !0 = metadata !{double 2.5} >> >> indicates that t...

...ngle "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 produce settings that match GCC's -ffast-math, however frontends will be able to specify whatever settings they like if that doesn't suit them (i.e. createFPMath will get more arguments as more settings become available). Note that as the current option isn'...

On Tue, Apr 17, 2012 at 9:16 AM, Renato Golin <rengolin at systemcall.org> wrote: > With FP precision, you might be able to use different instructions or > ignore specific traps on more relaxed models, and the back-end can > only know that if you kept the metadata until the end. > > I appreciate the cost of strict metadata semantics to the IR, but I > think we're at a

Hi, >> I am also not sure if it is at all possible to design a metadata >> system that allows passes to ignore it. I don't think that is true for >> any metadata we have other than debug info (if you don't consider >> broken debug info). >> >> IMHO the advantage that is still left in using metadata is that it is >> easier to implement gradually,

...'fast'. + return !isa<ConstantFP>(MD->getOperand(0)); Here as well. + if (ConstantFP *CFP0 = dyn_cast_or_null<ConstantFP>(Op0)) { + APFloat Accuracy = CFP0->getValueAPF(); + Assert1(Accuracy.isNormal() && !Accuracy.isNegative(), + "fpmath accuracy not a positive number!", &I); To be pedantic for a moment, zero is not a positive number. What about asserting these individually to give us more clear asserts if they fire? That also makes the string easier to write: "fpmath accuracy is a negative number!". + /// Set...