<div class="gmail_quote">On Sun, Apr 15, 2012 at 1:20 PM, Renato Golin <span dir="ltr"><<a href="mailto:rengolin@systemcall.org">rengolin@systemcall.org</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">On 15 April 2012 09:07, Duncan Sands <<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>> wrote:<br>
> Link-time optimization will sometimes result in "fast-math" functions being<br>
> inlined into non-fast math functions and vice-versa.  This pretty much<br>
> inevitably means that per-instruction fpmath options are required.<br>
<br>
</div>I guess it would be user error if a strict function used the results<br>
of a non-strict function (explicitly compiled with -ffast-math) and<br>
complain about loss of precision. In that case, the inlining keeping<br>
the option per-line makes total sense.<br></blockquote><div> </div><div>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.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Would there be need to make fast-math less strict, ie. to only use it<br>
when no strict FP result needs its result? In this case, an option in<br>
the whole function would guarantee that all inlined instructions would<br>
be modified to strict, even if relaxed in the first place.<br></blockquote><div><br></div><div>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.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Just guessing for the future, I agree with you that the first<br>
implementation should be very simple, as it is.<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br>