<div dir="ltr"><div>There was a pretty lengthy discussion on this a few months ago - <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063845.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063845.html</a><br>
I think people were mostly for the idea, but I don't know how far, if at all, they implemented these ideas.<br>If the diagnostic/warning capabilities are good enough, I think it'll be an interesting thing to have.<br>
</div><div>Also, Paul Redmond implemented something of the sort with the vectorizer and provided a few patches in that thread. It might help for implementing, testing or reasoning about what you're proposing.<br></div>
<div><br></div>H<br><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 9, 2013 at 9:21 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On 9 November 2013 15:03, Henrique Santos <span dir="ltr"><<a href="mailto:henrique.nazare.santos@gmail.com" target="_blank">henrique.nazare.santos@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_extra">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>
<div><div><div>
It seems like a difficult thing to do since we would have to keep metadata intact across transformations, which, AFAIK, is not done.<br>mem2reg, for example, doesn't even propagate debug metadata to phi nodes, and I'm not really sure if it's valid to do so.<br>

</div></div></div></div></div></blockquote><div><br></div></div><div>I understand that for most micro opts (delete, combine, coalesce, simplify, etc), this would be pointless. But for big things, like the vectorizers, it could be an interesting tool in addition to the sanitizers, since at that point, we'd have a lot more information than in the front-end (vector sizes, types, costs, etc). In those cases, I don't think we need that much debug info.</div>

<div><br></div><div>Line information should be enough for big things, and that's reasonably kept, even at O3. For instance, if a loop is inlined into another function, it'll contain the original line info, which is helpful. Also, if a function is inlined into a loop, and the SLP-vectorizer has warnings, it'll also point to the original function. It shouldn't be hard to include the function name in the warning (to know where it was inlined into, for example).</div>

<div><div><br></div></div><div>I'm thinking of making the optimization passes help the front-end(s), the same way PGO helps the optimization passes.</div><div><br></div><div>cheers,</div><div>--renato</div></div><br>
</div>
</div>
</blockquote></div><br></div>