<div class="gmail_quote">On Sun, Apr 15, 2012 at 3:50 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="gmail_quote"><div class="im">On Sun, Apr 15, 2012 at 3:53 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">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><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><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.</div></div></blockquote><div><br></div><div>And I don't disagree, I just think it is premature until we have measured an issue with the simpler form. Since we will almost certainly need the simpler form anyways, we might as well wait until the problem manifests.</div>
<div><br></div><div>The reason I don't expect it to get worse with more complex specifications is because the actual metadata nodes are uniqued. Thus we should see many instructions all referring to the same (potentially complex) node.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div> 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></blockquote><div><br></div><div>The IR is not a normalized representation already though. It's primary consumer and producer are libraries and machines, not humans. Debug metadata, TBAA metadata, and numerous other complexities are already present.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<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></blockquote><div><br></div><div>Yep, I'm just trying to explain my perspective on these issues. =] </div>
</div>