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

Owen Anderson resistor at mac.com
Mon Apr 16 10:25:02 PDT 2012


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 less precise than whatever the standard mode is.  However, C is notably sparse in specifying what exactly the standard mode is.  The typical assumption is that it is the strict one-to-one translation to IEEE754 semantics, but no optimizing C compiler actually implements that.

Other languages are more interesting in this regard.  Fortran, for instance, allows reassociation within parentheses.  (Can that even be represented with instruction metadata?)  OpenCL has a very fairly baseline mode, but specifies a number of specific options the user can enable to relax it (-cl-mad-enable, -cl-no-signed-zeros, -cl-unsafe-math-optimization (implies the previous two), -cl-finite-math-only, -cl-fast-relaxed-math (implies all prior)).  GLSL has distinct desktop and embedded specifications that place different levels of constraint on implementations.

If we define the baseline behavior to be strict IEEE conformance, and then don't provide a more nuanced method of relaxing it, we're not going to be in a significantly better world than we are today.  No reasonable implementation of these languages wants strict conformance (except maybe desktop-profile OpenCL) as their default mode, nor is there any way a universal definition of "fast" math can work for all of them.

--Owen

On Apr 14, 2012, at 11:28 AM, 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.
> <fastm-llvm.diff><fastm-clang.diff>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list