[LLVMdev] Proposal: floating point accuracy metadata (OpenCL related)

[Peter Collingbourne]

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,
-- 
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Annotate-imprecise-FP-division-with-fpaccuracy-metad.patch
Type: text/x-diff
Size: 3929 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110907/1961cf40/attachment.patch>