similar to: [LLVMdev] some thoughts on the semantics of !fpmath

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

On Apr 16, 2012, 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

> 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

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

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 intended behavior. -- With best regards, Anton Korobeynikov Faculty of

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

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

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

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

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

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 allowed to treat a meta-data annotated instruction >> as having the same semantics as an unannotated

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

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 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, This is my proposal to add floating point accuracy support to LLVM. The intention is that the frontend may provide metadata to signal to the backend that it may select a less accurate (i.e. more efficient) instruction to perform a given operation. This is primarily a requirement of OpenCL, which specifies that certain floating point operations may be computed inaccurately. Comments