[LLVMdev] Representing -ffast-math at the IR level

Dmitry Babokin babokin at gmail.com
Sat Apr 14 12:35:44 PDT 2012


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 future) is not enough without strict definition of this
keyword in terms of IR transformations. For example, particular
transformation may be interested if reassociation is allowed or not
((a+b)+c=> a+(b+c)), if fp contraction is allowed or not (ab+c =
>fma(a,b,c)), if addition of zero may be canceled (x+0=>x) and etc. If this
definition is not given on infrastructure level, this may lead to disaster,
when each transformation interprets "fast" in its own way.

Dmitry.

On Sat, Apr 14, 2012 at 10:28 PM, Duncan Sands <baldrick at free.fr> wrote:

> 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 !{double 2.5}
>
> indicates that the multiplication can be done in any way that doesn't
> introduce
> more than 2.5 ULPs of error.
>
> The first observation is that !fpmath can be extended with additional
> operands
> in the future: operands that say things like whether it is OK to assume
> that
> there are no NaNs and so forth.
>
> This patch doesn't add additional operands though.  It just allows the
> existing
> accuracy operand to be the special keyword "fast" instead of a number:
>
>    %z = fmul float %x, %y, !fpmath !0
>  ...
>  !0 = metadata !{!metadata "fast"}
>
> This indicates that accuracy loss is acceptable (just how much is
> unspecified)
> for the sake of speed.  Thanks to Chandler for pushing me to do it this
> way!
>
> It also creates a simple way of getting and setting this information: the
> FPMathOperator class: you can cast appropriate instructions to this class
> and then use the querying/mutating methods to get/set the accuracy, whether
> 2.5 or "fast".  The attached clang patch uses this to set the openCL 2.5
> ULPs
> accuracy rather than doing it by hand for example.
>
> In addition it changes IRBuilder so that you can provide an accuracy when
> creating floating point operations.  I don't like this so much.  It would
> be more efficient to just create the metadata once and then splat it onto
> each instruction.  Also, if fpmath gets a bunch more options/operands in
> the future then this interface will become more and more awkward.  Opinions
> welcome!
>
> I didn't actually implement any optimizations that use this yet.
>
> I took a look at the impact on aermod.f90, a reasonably floating point
> heavy
> Fortran benchmark (4% of the human readable IR consists of floating point
> operations).  At -O3 (the worst), the size of the bitcode increases by
> 0.8%.
> No idea if that's acceptable - hopefully it is!
>
> Enjoy!
>
> Duncan.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120414/90dd087d/attachment.html>


More information about the llvm-dev mailing list