[cfe-dev] Proposal: floating point accuracy metadata (OpenCL related)

[Robert Quill]

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.
> 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 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
> 	consecutive floating-point numbers a and b, without being
> 	equal to one of them, then ulp(x) = |b - a|, otherwise
> 	ulp(x) is the distance between the two non-equal finite
> 	floating-point numbers nearest x. Moreover, ulp(NaN) is
> 	NaN.
> 
> Implementation
> --------------
> 
> As a start, I am attaching a Clang patch which adds this metadata
> to single precision floating point division instructions in OpenCL
> (which are accurate to 2.5ulp, per OpenCL 1.1 s7.4).  I would imagine
> that in the future we may want to allow the user to control the level
> of accuracy (one idea is that we can provide a __builtin_fpaccuracy
> function, which could be used like this):
> 
> __builtin_fpaccuracy(x/y, 2) // compute x/y with a maximum error of 2ulp
> 
> The backend is not my area of expertise, so I won't venture to say
> how difficult it would be to recognise and act on the attribute there.
> 
> Alternatives
> ------------
> 
> I am proposing metadata here, since it may be removed without
> negatively affecting accuracy.
> 
> We could add fpaccuracy as a core LLVM attribute (a la nsw and nuw).
> But this would be relatively intrusive (only a few clients care about
> accuracy) and it would need to be added to a variety of unrelated
> instruction types (most floating point operations, as well as
> intrinsic calls).
> 
> We could also introduce a set of intrinsics for inaccurate FP
> operations.  The main disadvantage is that we would need to add an
> intrinsic for each FP operation, which could add up to a lot of work.
> Furthermore, the new intrinsics would not necessarily be recognised
> by the existing optimisers.
> 
> ------------------------------------------------------------------------
> 
> Thanks,
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev