<div dir="ltr">Thanks, it's #1 as you suggested, so that seems like a pretty good idea!</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 17, 2015 at 3:38 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@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"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On 17 February 2015 at 12:01, Hayden Livingston <span dir="ltr"><<a href="mailto:halivingston@gmail.com" target="_blank">halivingston@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 dir="ltr">Hello,<div><br></div><div>I'm currently developing a tool based on LLVM to understand how the LLVM IR changes after optimization passes are run.</div><div><br></div><div>Today it's a tedious but automatic process at a function level in my language, where I first dump the IR before running any passes, and then do it for the 10 or so passes I care about one-at-a-time to understand which pass affected the change.</div><div><br></div><div>There are two problems with this approach:</div><div><br></div><div>(1) One-at-time kills the usability of the tool for reasonable size functions, it takes too much time</div><div>(2) semi-manually identify how the IR changed, a diff that is not semantic but not entirely +/- either</div><div><br></div><div>While (1) is deal breaker, I have ideas on how to improve this in my tool.</div><div><br></div><div>However, on (2) -- I'm a bit lost without the help of the optimizer telling me what its doing. Have we ever envisioned creating passes that have callbacks to other LLVM or user code that would tell the interested party what changes they are about to make or made?</div><div><br></div><div>I understand that for some optimizers it's really an all-or-nothing approach, and they can't really pinpoint the line of IR that they are modifying or removing, but in general I feel a lot of optimizers could tell you which node in the IR they are about to modify.</div><div><br></div><div>So, on to my next thought. Is it feasible to somehow enforce or ask optimizers to do this, or would someone literally have to go through every optimizer and annotate it?</div><div><br></div><div>I'm new to this whole space, but would appreciate some comments on if there is already a half-decent way of achieving this?</div></div></blockquote><div><br></div></div></div><div>Here's one idea:</div><div><br></div><div>Between each optimization pass, iterate over every Instruction and build a CallbackVH for it. These will get callbacks upon certain operations such as deletion and RAUW'ing. Newly created instructions won't be in your list, so add them. If this is intended for a learning tool to observe things about llvm's inner operations this will work quite well.</div><div><br></div><div>If you need to track what's going on inside llvm for some purpose that requires exact tracking, you may want to try running llvm inside a VM that instruments every change to any Value or Use and collects a stack trace at that point (similarly to a watchpoint in gdb).</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Nick</div></font></span></div></div></div>
</blockquote></div><br></div>