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

[Duncan Sands]

Hi,

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

I agree with Chandler.  Also, don't forget that the safest way to proceed is to
start with a permissive interpretation of flags and tighten then up later.  For
example, suppose we start with an fpaccuracy of "fast" meaning: ignore NaN's,
ignore infinities, do whatever you like; and then later tighten it to mean: do
the right thing with NaN's and infinities, only introduce a bounded number of
ULPs of error.  Then this is conservatively safe: existing bitcode created with
the loose semantics will be correctly optimized and codegened with the new
tight semantics (just less optimized than it used to be).  However if we start
with tight semantics and then decide later that it was too tight, then we are
in trouble since existing bitcode might then undergo optimizations that the
creator of the bitcode didn't want.  So I'd rather start with a quite permissive
setup which seems generally useful and allows the most important optimizations,
and worry about decomposing and tightening it later.

Given the fact that no-one was interested enough to implement any kind of
relaxed floating point mode in LLVM IR in all the years gone by, I actually
suspect that there might never be anything more than just this simple and not
very well defined 'fast-math' mode.  But at least there is a clear path for
how to evolve towards a more sophisticated setup.

Ciao, Duncan.