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

Hal Finkel hfinkel at anl.gov
Sun Apr 15 06:08:43 PDT 2012


On Sun, 15 Apr 2012 14:28:13 +0400
Dmitry Babokin <babokin at gmail.com> wrote:

> On Sun, Apr 15, 2012 at 1:20 PM, Renato Golin
> <rengolin at systemcall.org>wrote:
> 
> > On 15 April 2012 09:07, Duncan Sands <baldrick at free.fr> wrote:
> > > Link-time optimization will sometimes result in "fast-math"
> > > functions
> > being
> > > inlined into non-fast math functions and vice-versa.  This pretty
> > > much inevitably means that per-instruction fpmath options are
> > > required.
> >
> > I guess it would be user error if a strict function used the results
> > of a non-strict function (explicitly compiled with -ffast-math) and
> > complain about loss of precision. In that case, the inlining keeping
> > the option per-line makes total sense.
> >
> 
> It's not a user error. User knows his code and accuracy of his code
> much better, than any compiler could possible do and may have strong
> reasons to specify fast-math for one function and not specify for
> another.

I strongly agree. Scientific users often compile different functions
with different floating-point accuracy flags and it is important to
respect that. Furthermore, a function that requires high accuracy can
use a low accuracy result as part of the computation. Doing so is
commonplace. As a quick example, a result could be:

result = (high accuracy result near 1) + 1e-10 * (low accuracy result
near 1).

 -Hal

> 
> >
> > Would there be need to make fast-math less strict, ie. to only use
> > it when no strict FP result needs its result? In this case, an
> > option in the whole function would guarantee that all inlined
> > instructions would be modified to strict, even if relaxed in the
> > first place.
> >
> 
> If the user specified different fp-models to different functions on
> purpose, the most likely you'll ruin performance by assuming stricter
> model the result of inlining.
> 
> >
> > Just guessing for the future, I agree with you that the first
> > implementation should be very simple, as it is.
> >
> > cheers,
> > --renato
> >



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-dev mailing list