<div dir="ltr">Sorry to dig up an old email, but I'm going through the history here, and I think this is the right place to comment on one particular aspect of this design:<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 11, 2015 at 4:03 PM Hal Finkel via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@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">> I think a larger problem here may be that we actually need<br>
> post-dominance information, as in "does this load instruction<br>
> post-dominate an invariant_start (associated with the loaded-from<br>
> pointer values), and if an equivalent invariant_end exists, does it<br>
> not post-dominate but rather dominate the invariant_end?"...<br>
> However, I also understand from Chandler that LLVM has a history of<br>
> avoiding post-dominance info computation in part because it is just<br>
> too expensive.<br>
<br>
Having post-dominance information is the right solution here, and that's what you should use. Yes, we've traditionally through of it as expensive, but that seems less a function of theory than of infrastructure. Computing dominance information is also expensive, but we mitigate this by caching the analysis, and actively updating it to avoid unnecessary invalidations.<br>
<br>
Last I spoke to Chandler about this, it seemed like the right way to go about this was to compute a post-dominance tree (which is, strictly speaking, not really a tree because it can have multiple roots), at least for those blocks reachable from the entry block, as part of the same walk that computes the dominator tree. Then we need to update it whenever we update the dominator tree. If we do that, it won't be expensive, and we can use it.<br></blockquote><div><br></div><div>While I generally agree that this is the right direction for the LLVM project, I don't think that this patch is the right place to force the issue.</div><div><br></div><div>Specifically, there is a very large amount of infrastructure work which will need to be done to make post-dominators readily available. As you outline, we'll need to change the postdom pass, and teach *many* other passes to preserve it when they currently preserve the dominator tree. I *do* think we should do this, but I don't think that we should hold up invariants until that is ready.</div><div><br></div><div>So I think the correct direction for the initial work on invariants is to figure out the conservatively correct approach *without* post-dominance information, and leave clear comments about how to augment the results when post-dominance becomes readily available.</div></div></div>