search for: fpaccuracy

...tion. This is primarily a requirement of OpenCL, which specifies that certain floating point operations may be computed inaccurately. Comments appreciated. ------------------------------------------------------------------------ Specification ------------- The metadata attribute is named "fpaccuracy", and contains a single integer parameter which specifies the maximum relative error of the operation to which it is attached, in ULPs. For the definition of ULPs we follow the definition given in the OpenCL 1.1 specification (section 7.4): If x is a real number that lies between two finite...

...which specifies that certain floating point > operations may be computed inaccurately. > > Comments appreciated. > > ------------------------------------------------------------------------ > > Specification > ------------- > > The metadata attribute is named "fpaccuracy", and contains a single > integer parameter which specifies the maximum relative error of the > operation to which it is attached, in ULPs. For the definition of > ULPs we follow the definition given in the OpenCL 1.1 specification > (section 7.4): > > If x is a real numbe...

...; operations may be computed inaccurately. > > > > Comments appreciated. > > > > --------------------------------------------------------------------- > --- > > > > Specification > > ------------- > > > > The metadata attribute is named "fpaccuracy", and contains a single > > integer parameter which specifies the maximum relative error of the > > operation to which it is attached, in ULPs. For the definition of > > ULPs we follow the definition given in the OpenCL 1.1 specification > > (section 7.4): > > &g...

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

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

...(fpextend x), (fpextend y)) to fdiv(x, y). Because double precision floating point divides are accurate in OpenCL, the single precision divide in the optimised code must also be accurate, unlike a "direct" single precision divide. I would imagine that creating a pinned metadata name for fpaccuracy, as we currently do for dbg, tbaa and prof, would go some way towards addressing the efficiency problem. Thanks, -- Peter

...nobody uses MDNode the way it is designed then eventually they will disappear from llvm. Don't worry. TBAA is one example. My value-range example was another. Here are some more: dbg: If someone mutates an instruction in place, it may not produce the value that the metadata was intended for. fpaccuracy: If the optimizer CSE's two operations with different accuracies, it might happen to keep the less accurate one. prof: If a branch condition is inverted, the frequency data is backward. nontemporal: If the optimizer cache-blocks a loop, it could greatly reduce the amount of time before a stor...

...ted code at the same time. Currently, our work is supported by the Erlang/OTP team and it has reached a complete and robust state. Thus, we would like to submit some patches to the LLVM project to support our work on ErLLVM. Our patches (applied on current Git ToT as of: "5e5c5f8 Rename 'fpaccuracy' metadata to the more generic 'fpmath'...") involve: 1) A new calling convention (& register pinning as explained in [4]). Touches: - include/llvm/CallingConv.h - lib/Target/X86/X86CallingConv.td - lib/Target/X86/X86ISelLowering.cpp - lib/Target/X86/X86RegisterInfo.cpp &&...

...gt; > Currently, our work is supported by the Erlang/OTP team and it has reached a > complete and robust state. Thus, we would like to submit some patches to the > LLVM project to support our work on ErLLVM. > > Our patches (applied on current Git ToT as of: "5e5c5f8 Rename 'fpaccuracy' > metadata to the more generic 'fpmath'...") involve: > > 1) A new calling convention (& register pinning as explained in [4]). > > Touches: > - include/llvm/CallingConv.h > - lib/Target/X86/X86CallingConv.td > - lib/Target/X86/X86ISelLowering.cpp >...

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 metadata is only supposed to exclude >> possible runtime conditions, rather than to intro...

...ent all the optimizations within that spec which existing applications > rely on for performance. I agree with Chandler. Also, don't forget that the safest way to proceed is to start with a permissive interpretation of flags and tighten then up later. For example, suppose we start with an fpaccuracy of "fast" meaning: ignore NaN's, ignore infinities, do whatever you like; and then later tighten it to mean: do the right thing with NaN's and infinities, only introduce a bounded number of ULPs of error. Then this is conservatively safe: existing bitcode created with the loose s...

On Jan 27, 2012, at 5:00 PM, Dan Gohman wrote: > Not all of these are miscompiles, None I'd say, may be TBAA. > but the point is that valid but > naive optimizations can cause them to be actively misleading ... but not cause mis-compilation. Note, optimization passes are free to update info conveyed through MDNodes, if they want to. The "optional to update" while still

On Jan 30, 2012, at 10:08 AM, Devang Patel wrote: > > On Jan 27, 2012, at 5:00 PM, Dan Gohman wrote: > >> Not all of these are miscompiles, > > None I'd say, may be TBAA. Then you missed value ranges and fpaccuracy. Anyway, here are some examples of optimizations which aren't implemented yet, but which have been seriously considered: metadata to mark C++ copy constructors, to allow the optimizer to eliminate them. Metadata to mark C++ vtble pointers, to facilitate devirtualization. Metadata to implement...

[ removing cfe-dev from the cc list ] On Jan 27, 2012, at 1:31 PM, Dan Gohman wrote: > On Jan 27, 2012, at 11:20 AM, Devang Patel wrote: > >> >> On Jan 26, 2012, at 2:10 PM, Dan Gohman wrote: >> >>> On Jan 26, 2012, at 12:54 PM, Devang Patel wrote: >>>> >>>> On Jan 26, 2012, at 11:15 AM, Dan Gohman wrote: >>>>

On Tue, Jan 24, 2012 at 12:02 PM, Bill Wendling <wendling at apple.com> wrote: > On Jan 24, 2012, at 1:35 AM, Chandler Carruth wrote: > > > On Wed, Jan 18, 2012 at 1:36 PM, Bill Wendling <wendling at apple.com> > wrote: > > Hello, > > > > This is a proposal for implementing "module flags". Please take a look > at this and give any feedback

...our work is supported by the Erlang/OTP team and it has reached a > > complete and robust state. Thus, we would like to submit some patches to the > > LLVM project to support our work on ErLLVM. > > > > Our patches (applied on current Git ToT as of: "5e5c5f8 Rename 'fpaccuracy' > > metadata to the more generic 'fpmath'...") involve: > > > > 1) A new calling convention (& register pinning as explained in [4]). > > > > Touches: > > - include/llvm/CallingConv.h > > - lib/Target/X86/X86CallingConv.td > > -...

On Jan 27, 2012, at 11:20 AM, Devang Patel wrote: > > On Jan 26, 2012, at 2:10 PM, Dan Gohman wrote: > >> On Jan 26, 2012, at 12:54 PM, Devang Patel wrote: >>> >>> On Jan 26, 2012, at 11:15 AM, Dan Gohman wrote: >>> >>>> or what optimizers must do to preserve it. >>> >>> The number one reason behind metadata is to have a

I feel like this discussion is getting a bit off track... On Sun, Apr 15, 2012 at 12:00 AM, Dmitry Babokin <babokin at gmail.com> wrote: > > I would define the set of transformations, such as (i can help with more > complete list if you prefer): > > - reassociation > - x+0.0=>x > - x*0.0=>0.0 > - x*1.0=>x > - a/b => a* 1/b > -

On Jan 24, 2012, at 1:35 AM, Chandler Carruth wrote: > On Wed, Jan 18, 2012 at 1:36 PM, Bill Wendling <wendling at apple.com> wrote: > Hello, > > This is a proposal for implementing "module flags". Please take a look at this and give any feedback you may have. > > Thanks! > -bw > > I have only one real comment -- this violates the contract and spirit