search for: fpaccuraci

Displaying 19 results from an estimated 19 matches for "fpaccuraci".

Did you mean: fpaccuracy
2011 Sep 07
3
[LLVMdev] Proposal: floating point accuracy metadata (OpenCL related)
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
2011 Sep 08
1
[LLVMdev] [cfe-dev] Proposal: floating point accuracy metadata (OpenCL related)
Hi Peter, This sounds like I really good idea. One thing that did occur to me though from an OpenCL point of view is that ULP accuracy requirements can differ for embedded and full profile so that may need to be handled somehow. Thanks, Rob On Wed, 2011-09-07 at 21:55 +0100, Peter Collingbourne wrote: > Hi, > > This is my proposal to add floating point accuracy support to LLVM. >
2011 Sep 08
0
[LLVMdev] [cfe-dev] Proposal: floating point accuracy metadata (OpenCL related)
Peter, Is there a way to make this flag globally available? Metadata can be fairly expensive to handle at each node when in many cases it is a global flag and not a per operation flag. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Robert Quill > Sent: Thursday, September 08, 2011 3:24 AM > To: Peter
2012 Apr 17
0
[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
2012 Apr 16
6
[LLVMdev] some thoughts on the semantics of !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
2011 Sep 08
1
[LLVMdev] [cfe-dev] Proposal: floating point accuracy metadata (OpenCL related)
On Thu, Sep 08, 2011 at 11:15:06AM -0500, Villmow, Micah wrote: > Peter, > Is there a way to make this flag globally available? Metadata can be fairly expensive to handle at each node when in many cases it is a global flag and not a per operation flag. There are two main reasons why I think we shouldn't go for global flags: 1) It becomes difficult if not impossible to correctly link
2012 Jan 28
2
[LLVMdev] [RFC] Module Flags Metadata
On Jan 27, 2012, at 3:40 PM, Devang Patel wrote: > [ 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:
2012 Apr 14
2
[LLVMdev] RFC: ErLLVM - An LLVM backend for Erlang
Hi, We 've been working on an LLVM backend for High Performance Erlang (HiPE) [1], the native code compiler of Erlang/OTP [2]. ErLLVM [3] targets the X86 and AMD64 architectures for now but there is some ongoing work from a team on the Uppsala University to also support ARM. In our implementation, we have paid special attention on retaining ABI-compatibility with the Erlang Runtime System in
2012 Apr 24
0
[LLVMdev] RFC: ErLLVM - An LLVM backend for Erlang
Hi, Following Chris' advice, I will rebase the patches and break them in 3 distinct emails (one at a time) in order to be easier for a reviewer to approve/comments. Please note that the three patches while being code-wise independent, they 're strongly-connected *semantically*, meaning that including just a subset of these patches to LLVM's code base is quite weak if the others are
2012 Apr 17
1
[LLVMdev] some thoughts on the semantics of !fpmath
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
2012 Apr 15
0
[LLVMdev] Representing -ffast-math at the IR level
Hi, > I would love to see such detailed models if we have real use cases and people > interested in implementing them. > > However, today we have a feature in moderately widespread use, '-ffast-math'. > It's semantics may not be the ideal way to enable restricted, predictable > optimizations of floating point operations, but they are effective for a wide > range
2012 Jan 30
0
[LLVMdev] [RFC] Module Flags Metadata
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
2012 Jan 30
2
[LLVMdev] [RFC] Module Flags Metadata
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
2012 Jan 27
0
[LLVMdev] [RFC] Module Flags Metadata
[ 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: >>>>
2012 Jan 24
0
[LLVMdev] [RFC] Module Flags Metadata
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
2012 Apr 24
2
[LLVMdev] RFC: ErLLVM - Implemented HiPE Calling Convention
This patch (and the others that will follow) are rebased on svn r155440: "AVX2: The BLENDPW instruction selects between vectors of v16i16 using an i8 immediate. We can't use it here because the shuffle code does not check that the lower part of the word is identical to the upper part" Patch 1/3: The attached commits add a new calling convention to support the LLVM backend for
2012 Jan 27
3
[LLVMdev] [cfe-dev] [RFC] Module Flags Metadata
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
2012 Apr 14
4
[LLVMdev] Representing -ffast-math at the IR level
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 > -
2012 Jan 24
6
[LLVMdev] [RFC] Module Flags Metadata
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