I feel like this discussion is getting a bit off track...<br><br><div class="gmail_quote">On Sun, Apr 15, 2012 at 12:00 AM, Dmitry Babokin <span dir="ltr"><<a href="mailto:babokin@gmail.com">babokin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><div><br></div></div><div>I would define the set of transformations, such as (i can help with more complete list if you prefer):</div>
<div><ul>
<li>reassociation</li><li>x+0.0=>x</li><li>x*0.0=>0.0</li><li>x*1.0=>x</li><li>a/b => a* 1/b</li><li>a*b+c=>fma(a,b,c)</li><li>ignoring NaNs in compare, i.e. (a<b) => !(a>=b)</li><li>value unsafe transformation (for aggressive fp optimizations, like a*b+a*c => a(b+c)) and other of the kind.</li>

</ul><div>and several aliases for "strict", "precise", "fast" models (which are effectively combination of flags above).</div></div><div><br></div><div>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.</div>
</blockquote><div><br></div><div>I would love to see such detailed models if we have real use cases and people interested in implementing them.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>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.</div></blockquote></div><br><div>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.</div>
<div><br></div><div>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.</div>