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

[Chandler Carruth]

I feel like this discussion is getting a bit off track...

On Sun, Apr 15, 2012 at 12:00 AM, Dmitry Babokin <babokin at gmail.com> wrote:

>
> I would define the set of transformations, such as (i can help with more
> complete list if you prefer):
>
>    - reassociation
>    - x+0.0=>x
>    - x*0.0=>0.0
>    - x*1.0=>x
>    - a/b => a* 1/b
>    - a*b+c=>fma(a,b,c)
>    - ignoring NaNs in compare, i.e. (a<b) => !(a>=b)
>    - value unsafe transformation (for aggressive fp optimizations, like
>    a*b+a*c => a(b+c)) and other of the kind.
>
> and several aliases for "strict", "precise", "fast" models (which are
> effectively combination of flags above).
>
> So that metadata would be able to say "fast", "fast, but no fma allowed",
> "strict, but fma allowed", I.e. metadata should be a base-level + optional
> set of adjustments from the list above.
>

I would love to see such detailed models if we have real use cases and
people interested in implementing them.

However, today we have a feature in moderately widespread use,
'-ffast-math'. It's semantics may not be the ideal way to enable
restricted, predictable optimizations of floating point operations, but
they are effective for a wide range of programs today.

I think having a generic flag value which specifically is attempting to
model the *loose* semantics of '-ffast-math' is really important, and I
think any more detailed framework for classifying and enabling specific
optimizations should be layered on afterward. While I share our frustration
with the very vague and hard to reason about semantics of '-ffast-math', I
think we can provide a clear enough spec to make it implementable, and we
should give ourselves the freedom to implement all the optimizations within
that spec which existing applications rely on for performance.

And, again, I think this should be function level model, unless specified
> otherwise in the instruction, as it will be the case in 99.9999% of the
> compilations.
>

I actually lobbied with Duncan to use a function default, with instruction
level overrides, but his posts about the metadata overhead of just doing it
on each instruction, I think his approach is simpler.

As he argued to me, *eventually*, this has to end up on the instruction in
order to model inlining correctly -- a function compiled with '-ffast-math'
might be inlined into a function compiled without it, and vice versa. Since
you need this ability, it makes sense to simplify the inliner, the metadata
schema, etc and just always place the data on the instructions *unless*
there is some significant scaling problem. I think Duncan has demonstrated
it scales pretty well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120415/b539e122/attachment.html>