<div class="gmail_quote">On Sun, Apr 15, 2012 at 3:53 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com">chandlerc@google.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="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>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.</blockquote>
</div></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>
</blockquote><div><br></div><div>For simple metadata, like "fast" in initial proposal, it could be ok. But if more complex metadata is possible (like I've described), then this approach could consume more bitcode size, than expected. And I'm sure there will be attempts to add fine-grain precision control. And the first candidate is probably enabling/disable FMAs.</div>
<div><br></div><div>Inlining is a valid concern, though inside the single module fp model will be the same in absolute majority of cases. People also tend to have consistent flags across the project, so it shouldn't be rare case when it's consistent between modules.</div>
<div><br></div><div>Function or module level default setting is really just an optimization, but IMHO quite useful one. It would also simplify dumps and understanding of what is going on for people who don't want dig into details of fp precision problems and be distracted by additional metadata.</div>
<div><br></div><div>Just to be clear. As it's not me, who is going to implement this, I'm just try to draw an attention to the issues that we'll finally encounter down the road.</div><div><br></div><div>Dmitry.</div>
</div>