<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, 26 Sep 2018 at 17:54, Fedor Sergeev via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings!<br>
<br>
As the generic Pass Instrumentation framework for new pass manager is <br>
finally *in*,<br>
I'm glad to start the discussion on implementation of -opt-bisect <br>
through that framework.<br>
<br><br></blockquote><div>I don't think I can help this discussion, but I would like to understand the context of it.</div><div>Do we have any requirements?</div><div>What are the use cases that "opt-bisect" is intended to help with?</div><div><br></div><div>Some use cases that I would like to understand are:</div><div>Q1) Take LLVM IR instruction X.</div><div>Which pass removed it (optimized it out) ?</div><div>Q2) Take LLVM IR instruction X.</div><div>Run pass Y once. Leaves instruction X in there.</div><div>Run pass Y a second time should not then remove instruction X.</div><div>My thinking that if pass Y was doing its job correctly, it should have removed instruction X on the first pass Y. i.e. pass Y should not be lazy.<br></div><div>One problem with the "lazy" approach, is "How many times should pass Y be run?"</div><div>Q3) Do any LLVM IR passes do delayed instruction elimination?</div><div>I.e.</div><div>Pass 1 marks some instructions for removal.</div><div>Pass 2 marks some more instructions for removal.</div><div>Pass 3 actually removes the instructions. (the expensive bit where caches, indexes etc. need rebuilding)</div><div>I only mention this Q3, because I think it could affect the way opt-bisect should work. (see Q1 above) Should the answer be Pass 1 or Pass 3 ?</div><div><br></div><div></div><div></div><div>Is opt-bisect something that can help with these use cases?</div><div><br></div><div>Kind Regards</div><div><br></div><div>James</div><div><br></div></div></div>