<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 16, 2018, at 2:30 PM, Son Tuan VU <<a href="mailto:sontuan.vu119@gmail.com" class="">sontuan.vu119@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Vedant,<div class=""><br class=""></div><div class="">Thank you for your reply. I think I can make this debugify-each mode, but I guess this is reserved for your GSoC project ?</div></div></div></blockquote><div><br class=""></div><div>No, there's no reserved work. If you'd like to work on this I encourage you to do so. There's plenty of other work slated for the GSoC project. That said, let's make sure to sync up on the mailing lists to make sure work isn't being duplicated.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">However, if I understand correctly, we do not want to take the output of the first check-debugify (I mean the .ll file with potentially all the WARNINGs and ERRORs after the first pass) as input for the second debugify. What we need is to take the fresh output of <b class="">clang -Xclang -emit-llvm -disable-O0-optnone -S </b>and iteratively test each optimization. Am I right?</div></div></div></blockquote><div><br class=""></div><div>The intermediate textual output is all irrelevant. And clang isn't in the picture here. Opt's regular mode of operation is to run pass1, then run pass2, etc. In the debugify-each mode, this instead looks like: debugify, pass1, check-debugify, strip debug info, debugify, pass2, etc. etc.</div><div><br class=""></div><div>vedant</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class="">Son Tuan Vu</div></div></div>
<br class=""><div class="gmail_quote">On Thu, Mar 15, 2018 at 4:05 AM, Vedant Kumar <span dir="ltr" class=""><<a href="mailto:vsk@apple.com" target="_blank" class="">vsk@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Hi Son Tuan,<div class=""><br class=""></div><div class="">Thanks for taking a look at this :). Responses inline --</div><div class=""><br class=""></div><div class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Mar 14, 2018, at 8:11 AM, Son Tuan VU <<a href="mailto:sontuan.vu119@gmail.com" target="_blank" class="">sontuan.vu119@gmail.com</a>> wrote:</div><br class="m_251843486385049358Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Vedant, hi all,<div class=""><br class=""></div><div class="">My goal is to measure debug info loss of <i class="">each</i><b class=""> </b>optimization pass in LLVM. I am trying to create a debugify-each mode in opt, inspired by verify-each mode which is supposed to already work.</div></div></div></blockquote><div class=""><br class=""></div></span>+ Anastasis, who's interested in working on this as well. There's definitely enough work to go around: once we can measure debug info loss after each pass, we'll need a testing harness.</div><div class=""><br class=""></div><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">However, if I understand correctly, the verify-each mode (triggered by -verify-each option in opt) only works when we provide a pass list or a pass pipeline.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Yes, you're correct.</div><span class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> Is this intended? I mean, why do not let people verify each pass in -O{1,2,3} pipeline?</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">That's a good question! Like you, I assumed -verify-each "does the right thing" when you pass -O1/-O2/etc. to opt.</div><div class=""><br class=""></div><div class="">I'm not sure if the current behavior is intended (hopefully others will chime in about this :). If no one does, please file a bug.</div><div class=""><br class=""></div><div class="">I imagine this is pretty simple to fix. You can just define and use custom pass managers within opt which inject debugify passes as needed:</div><div class=""><br class=""></div><div class=""><div class=""></div><blockquote type="cite" class=""><blockquote type="cite" class=""><div class="">// In opt.cpp:</div></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><div class="">class DebugifyEachFunctionPassManage<wbr class="">r : public legacy::FunctionPassManager {</div><div class="">public:</div><div class=""> explicit DebugifyEachFunctionPassManage<wbr class="">r(Module *M)</div><div class=""> : FunctionPassManager(M) {}</div><div class=""><br class=""></div><div class=""> void add(Pass *P) override {</div><div class=""> // FunctionPassManager::add(<<wbr class="">debugify>)</div><div class=""> FunctionPassManager::add(P);</div><div class=""> }</div><div class="">};</div></blockquote></blockquote><div class=""><br class=""></div></div><span class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">My second question is more about debugify: what should be the best way to debugify each pass? Adding a debugify-each mode would make the output unreadable!</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">The intermediate output is all irrelevant. I think it'd be best to simply throw it away. What really matters are the debug info loss statistics: we should capture these stats after each pass and dump them as JSON, at the end of the pipeline.</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">vedant</div></font></span><span class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> Maybe writing a script that collects all optimization options (like -mem2reg or -constmerge), then pass each one of them to opt with -enable-debugify so that we have 1 output file for each debugified pass?</div><div class=""><br class=""></div><div class="">Thank you for your help,</div><div class=""><br clear="all" class=""><div class=""><div class="m_251843486385049358gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class="">Son Tuan Vu</div></div></div>
</div></div>
</div></blockquote></span></div><br class=""></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>