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

[Anton Lokhmotov]

Hi Peter,

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

I'm a bit worried that accuracy metadata may be dropped or modified before
it reaches the backend.  Currently, an OpenCL backend can safely assume that
the division operation is the same as specified in the OpenCL standard (i.e.
with the maximum relative error of 2.5 ulps), and map it, say, to the native
division instruction.  If "no accuracy metadata" would mean "use correct
rounding", you are correct in that accuracy metadata could be dropped
without negatively affecting accuracy.  Dropping accuracy metadata could,
however, negatively affect performance, if the backend would have to go for
a slow software implementation instead of a fast hardware implementation.
If would be better if "no accuracy metadata" would mean "use the default
language accuracy", so only allowing for relaxing accuracy further.  But
then LLVM-IR would remain language-dependent.

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

The existing optimisers would need to be extended to recognise relaxed
accuracy requirements.  Otherwise, they could over-tighten them for safety
(again negatively affecting performance).

I suggest we discuss this on Friday at the LLVM developers' meeting in
London.

Best, Anton.