<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jan 13, 2016 at 2:00 AM 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">Actually, can you please remind me why we want post-dominance information here at all?</blockquote><div><br></div><div>FWIW, I also would like to see a clear explanation of this -- I haven't yet.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> For the invariant_start -> load, it seems like dominance information is what we want (all paths to the load need to pass through the invariant_start (or some invariant_start, should there be multiple ones for the same pointer). Regarding invariant_end, we need to make sure that no paths from the invariant_start to the load pass through an invariant_end. For this, it seems conservatively correct to check that the load dominates the invariant_end (or all invariant_ends, should there be multiple), and that any containing loop has backedges that branch to blocks dominating the invariant_start(s). We could use post-dom information for this check, but that's just a different approximation.<br></blockquote><div><br></div><div>Sure.</div><div><br></div><div>I think that your statement is really hitting on the critical point here though: the issue is whether the invariant ends between the start and the load, nothing else. As you demonstrate, postdom actually gets the wrong answer:</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
invariant_start<br>
/ \<br>
| load #1<br>
| |<br>
\ /<br>
\ /<br>
|<br>
load #2<br>
/ \<br>
/ \<br>
ret \<br>
invariant_end<br>
\<br>
\<br>
ret<br>
<br>
So in this case (assuming my attempt at ASCII-art is successful), both loads here can be considered to be invariant (both are dominated by the invariant_start, and there are no paths from the invariant_start to either load passing through an invariant_end). However, while it is true that load #2 is post-dominated by the invariant_end w.r.t. one of the exits, it is not w.r.t. all exits. load #1 here does not even post-dominate the invariant_start, and that's fine. However, load #1 does not dominate the invariant_end either.<br></blockquote><div><br></div><div>This is a great example. Larisse, this should really be a good test case for this patch.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Maybe we need a dedicated CFG walk to collect the necessary information?<br></blockquote><div><br></div><div>Yea. We check for the same kinds of things in a number of other places without post dominators. It might be useful to mirror the logic on them.</div><div><br></div><div>However, maybe there are easier ways. Thinking about this, for GVN in particular, I think I see really easy ways to make this fast and reasonably precise... Check my reasoning:</div><div><br></div><div>1) The start must dominate the load.</div><div>2) Therefore, if an end exists on a path from the start to the load, the start must dominate the end.</div><div>3) GVN never introduces ends or changes the dominance relationship of starts and ends.</div><div>4) We scan the function finding all of these intrinsics ahead of time already.</div><div>5) We can build a map from domtree node (or basic block essentially) to the list of invariant end intrinsics in that block.</div><div>6) We can walk the dom tree from the start to the load, and check each end in each block</div><div><br></div><div>I feel like I'm missing a case... do you see the hole in this plan?</div><div><br></div><div>It'll be a bit expensive because of the linear scan if there are a very large number of invariants. Maybe that's OK? Hard for me to tell...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Hal<br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</blockquote></div></div>