<div dir="ltr">This definitely needs an RFC.<div><br></div><div>I'll note your approach is badly O(N) in some cases.</div><div>You could try using the uses instead (they know what operand number and their uses).</div><div>I suspect that's hard to pass down everywhere in each pass.</div><div><br></div><div>In general If we are going to go this route, either we should: have a real CFG structure that isn't going to be O(N) to remove an edge.</div><div>or incrementally, cache data in basic blocks (successor, predecessor lists and uses) that gets invalidated, so you can find the removal points in constant time.</div><div><br></div><div>The latter is likely to require a lot of verification to not generate hard to track down bugs in the compiler.</div><div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 25, 2017 at 2:30 PM, Brian Rzycki via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">brzycki added a comment.<br>
<span class=""><br>
In <a href="https://reviews.llvm.org/D37575#880401" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D37575#880401</a>, @kuhar wrote:<br>
<br>
> I'm fine with the patch, I think it goes into right direction with CFG-level IR manipulation.<br>
</span>>  Please wait for someone else to give you a green light on this. Maybe it would be worth to mention this as an RFC on llvm-dev?<br>
<br>
<br>
Thanks for the review and you bring up a good point about RFC on llvm-dev. I'll make a post tomorrow morning and see where the conversation goes.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D37575" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D37575</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>