<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 31, 2011, at 11:22 AM, Nick Lewycky wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On 31 October 2011 10:23, Owen Anderson <span dir="ltr"><<a href="mailto:resistor@mac.com">resistor@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Nick,<br>
<br>
Isn't what you're computing here an approximation of immediate post-dominance? If we really want to handle this properly, it seems like we should just use the actual post-dominance computation rather than approximating it.<br>
</blockquote><div><br></div><div>Heh, an earlier version of my patch actually called that function FindPostIdoms.</div><div><br></div><div>No, simply looking at postdoms would actually do the wrong thing. Consider a CFG "A -> {B, C}, B -> D, C -> D": the matching postdom tree is "D -> {A, B, C}". Given a free in block D we would look for and delete stores in A. Trouble is, those aren't necessarily dead as there may be uses in B and C. That's why I explicitly check through the preds.</div>
</div></blockquote><br></div><div>OK, I see your point there. I guess this is another case where we want to have reverse MemDep.</div><div><br></div><div>I'm fine with this going in, but please check for compile-time regressions first. Inter-block DSE has been a source of regressions in the past.</div><div><br></div><div>--Owen</div><br></body></html>