<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 15, 2013 at 2:12 AM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br>
<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 class="gmail_extra"><div class="gmail_quote">
- non-intrusively collect detailed information/statistics about the optimization pipeline. For example, which pass is responsible for eliminating the most functions? Which pass is responsible for eliminating *this* instruction in my function?<br>

<div><br></div></div></div></div></blockquote><div><br></div><div>In general, improved observability into the optimization pipeline can have possibly huge knock-on effects for improving it.</div><div><br></div><div>Not entirely kidding:</div>
<div><br></div><div>A sort of "pass-pseudo-dtrace" could be implemented in a nicely independent way by defining "probes" at the various locations exposed by the "introspection" API (no actual dynamic instrumentation; it just executes stuff in those "introspection" callbacks). Silly strawman oneliner:</div>
<div>    opt -pass-pseudo-dtrace='pass:*::before { self->shl_before = curmodule["shl"].count() } pass:*::after /curmodule["shl"].count() <= self->shl_before -  5/ { print(curpassname, "managed to eliminate more than 5 shl's!") }' foo.bc</div>
<div>My experience with dtrace is that such trivially available observability and powerful ad-hoc queries (and the deeper investigations they lead to and facilitate) are the single most effective way to identify previously-unknown things that could be improved (or that are broken) in a system.</div>
<div>Even purely as a learning tool it might be worth having that.</div><div><br></div><div>How else would you answer the question "which passes eliminate shl's in a typical compilation"? (and that's just one of an open-ended class of queries that such a system would facilitate). </div>
<div><br></div><div>AFAIK the only way to currently answer that question is to drop down to C++, write a pass that gathers the statistics, hack up opt to insert these instrumentation passes between passes in the desired pipeline (or do some horrible brittle commandline transformation), rebuild things (possibly rebuilding most of LLVM if you don't already have an incremental build hot): end result is that it would take at least an order of magnitude more time (or even 2). If you have to shave a yak to get an answer, you ask fewer questions.</div>
<div><br></div><div>(Note: while you may be able to name some passes that eliminate shl's off the top of your head, it's precisely the ones that you *can't* think of off the top of your head that have the potential to expose unexpected properties of the system). Adding &&'s and ||'s quickly moves you into a realm where even gurus can at best guess: maybe a step up in complexity is: partition the set of passes into the 9 categories defined by "{add,remove,not change} load's && {add,remove,not change} shl's", are there any categories that are unpopulated?. And conjunctions and disjunctions barely scratch the surface of what such a "dtrace-like" system can easily access (e.g. how does the average integer size in the module change throughout the optimization pipeline? generate data that can be used for plotting a line-graph. Which passes have the largest impact on average integer size?).<br>
</div><div><br></div><div>-- Sean Silva</div></div></div></div>