similar to: [LLVMdev] 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. >

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

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

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

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

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

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

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

Dear LLVM contributors, I am Naoki Shibata, an associate professor at Nara Institute of Science and Technology. I and Hal Finkel would like to jointly propose to add my vectorized math library to LLVM. The library has been available as public domain software for years, I am going to double-license the library if necessary. ******** Below is a proposal to add my vectorized math library,

On Tue, Jun 17, 2014 at 10:11 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > If we require the host to have sse2 or other IEEE 754 conformant > implementation, would it be possible to use hardware float? > I don't think that IEEE 754 actually guarantees bit-exact results in all cases. -- Sean Silva > > Sent from my iPhone > > > On

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

> On Jan 12, 2017, at 2:21 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Jan 12, 2017, at 11:04 AM, Steve (Numerics) Canon <scanon at apple.com <mailto:scanon at apple.com>> wrote: >> >>> >>> On Jan 12, 2017, at 12:58 PM, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>

Full_Name: Nick Efthymiou Version: R1.5.0 and above OS: Red Hat Linux Submission from: (NULL) (162.93.14.73) With the introduction of the functions rowSums(), colSums(), rowMeans() and colMeans() in R1.5.0, function "SEXP do_colsum(SEXP call, SEXP op, SEXP args, SEXP rho)" was added to perform the fast summations. We have an excellent opportunity to improve the accuracy by

On Thu, Oct 13, 2011 at 11:57 AM, Peter Collingbourne <peter at pcc.me.uk>wrote: > Hi Justin, > > Thanks for bringing this up, I think it's important to discuss > these issues here. > > On Thu, Oct 13, 2011 at 09:46:28AM -0400, Justin Holewinski wrote: > > It is becoming increasingly clear to me that LLVM address spaces are not > the > > general solution

On Thu, Oct 13, 2011 at 04:14:09PM -0400, Justin Holewinski wrote: > On Thu, Oct 13, 2011 at 11:57 AM, Peter Collingbourne <peter at pcc.me.uk>wrote: > > > Hi Justin, > > > > Thanks for bringing this up, I think it's important to discuss > > these issues here. > > > > On Thu, Oct 13, 2011 at 09:46:28AM -0400, Justin Holewinski wrote: > >

The problem I want to address in this discussion is the representation of OpenCL/CUDA memory spaces in LLVM IR. As support for OpenCL and CUDA mature within Clang, it is important that we provide a way to represent memory spaces in a way that is (1) sufficiently generic that other language front-ends can easily emit the needed annotations, and (2) sufficiently specific that LLVM optimization

RFC: A proposal for vectorizing loops with calls to math functions using SVML (short vector math library). ========= Overview ========= Very simply, SVML (Intel short vector math library) functions are vector variants of scalar math functions that take vector arguments, apply an operation to each element, and store the result in a vector register. These vector variants can be generated by the