<div dir="ltr">I have written down my thoughts and added some of the feedback from this thread. The proposal is probably still sparse, but I would like to start the discussion so I can shape it into final documentation when we are done painting the bike shed.<br>
<br><a href="https://docs.google.com/document/d/1FYUatSjZZO-zmFBxjOiuOzAy9mhHA8hqdvklZv68WuQ/edit?usp=sharing" class="cremed">https://docs.google.com/document/d/1FYUatSjZZO-zmFBxjOiuOzAy9mhHA8hqdvklZv68WuQ/edit?usp=sharing</a><div>
<br></div><div>Please add your feedback on the document itself (anyone should be able to comment) or to this thread.</div><div><br></div><div>Tobias, I will look at your patches this week and start producing my own changes on top of them.</div>
<div><br></div><div><br></div><div>Thanks.  Diego.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 2:07 PM, Diego Novillo <span dir="ltr"><<a href="mailto:dnovillo@google.com" target="_blank">dnovillo@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 dir="ltr"><br><div>The context of this is performance analysis of generated code. My interest is to trace at a high-level the major decisions done by the various optimizers. For instance, when the inliner decides to inline foo into bar, or the loop unroller decides to unroll a loop N times, or the vectorizer decides to vectorize a loop body.</div>

<div><br></div><div>Many of these details are usually available via -debug-only. However, this has several limitations:</div><div><ol><li>The output is generally too detailed. Passes will often emit the result of their analysis, what failed, what worked, etc. This is often fine when debugging the pass itself, but it's too noisy for initial analysis.</li>

<li>The output is unstructured and it often uses pass-specific lingo which may confuse someone who just started looking at it.</li><li>It forces a debug+asserts build (or at least a build with -UNDEBUG).</li><li>Only one pass at a time can be asked to produce debugging output.</li>

</ol><div>Additionally, I don't think it's right to co-opt the -debug-only facility for implementing optimization reports. They have different purposes. An optimization report should simply state what the pass did in fairly terse way. This facilitates initial and comparative analysis. If I want to compare what one compiler did versus the current version, it would be easy to spot what decisions were made by each one.<br>

</div></div><div><br></div><div>Clearly, the quality of the information will depend on how many decisions are reported. Not every difference in performance will be detected by comparing optimization reports. But major differences are often due to major passes making slightly different decisions (e.g., the inliner).</div>

<div><br></div><div>My intent is to introduce an optimization report option to LLVM which passes will be able to use to indicate the major decisions they make. Initially, I am tempted to mimic GCC's -fopt-info (<a href="http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-fopt-info-747" target="_blank">http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-fopt-info-747</a>).</div>

<div><br></div><div>Before I get too far into this, do folks think this is a good idea? I'm open to reasonable requests on how the facility should work, etc.</div><div><br></div><div><br></div><div>Thanks. Diego.</div>

</div>
</blockquote></div><br></div>