<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 8:07 AM, Diego Novillo <span dir="ltr"><<a href="mailto:dnovillo@google.com" target="_blank">dnovillo@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Dec 7, 2015 at 10:18 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">rnk added a subscriber: rnk.<br>
rnk added a comment.<br>
<br>
I read through this, and tried to check my understanding of it with Larisse. Here's how I see things working:<br>
<br>
- GVN processes instructions in reverse post order. This means dominating blocks come first, i.e. defs before uses.<br>
- GVN's processInstruction calls llvm::processInvariantIntrinsic() on invariant intrinsics<br>
- This updates InvariantMap to hold values passed to invariant.start. A call to invariant.end will remove the pointer from the map, and a new invariant.start will overwrite it.<br>
- BasicAA has been modified to return MRI_NoModRef for addresses that are present in InvariantMap, as well as other things. This is what enables GVN to do better.<br>
- MemDep has been modified so that when it scans backwards across an invariant start, it won't still consider the memory to be constant and load something bad like undef.<br>
<br>
Fundamentally, the approach of having a side table populated by GVN's instruction visitation order makes me nervous, but I'm not able to construct a solid counterexample as to why.<br></blockquote><div><br></div></span><div>Keeping on the side data, outside of the IR can be a source of headaches, yes.  However, in this case this on-the side table is kept for the duration of the pass that invokes the analysis.  The only invalidation it needs to worry about is anything done by the invoking pass itself.</div><div><br></div><div>So, any problems caused by wrongfully moving instructions in/out of the invariant region would be localized.  Perhaps this could be alleviated by having invariant attributes on the instructions in the region and a verification step that checks them.  Larisse, do you think this is doable?</div></div></div></div></blockquote><div><br></div><div>Adding a new attribute/annotation is definitely doable, and probably a more general solution (if we consider later extensions in -globalopt for Global Variables). I am more concerned with this either opening up discussions about (what seems like) yet another syntactic extension or duplicating compiler workload... </div><div><br></div><div>I think a larger problem here may be that we actually need post-dominance information, as in "does this load instruction post-dominate an invariant_start (associated with the loaded-from pointer values), and if an equivalent invariant_end exists, does it not post-dominate but rather dominate the invariant_end?"... However, I also understand from Chandler that LLVM has a history of avoiding post-dominance info computation in part because it is just too expensive. </div><div><br></div><div>After further thoughts, and more to Diego's point about annotating instructions, I now understand Reid's point about these changes, though with localized effect at the moment, being dependent on the order in which instructions are processed. For extensibility and future-proof-ness reasons, this dependence will have to be reinforced somehow, or at the very least very well documented.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><font color="#888888"><div></div></font></span></div><span><font color="#888888"><br></font></span></div><span><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra">Diego</div></font></span></div>
</blockquote></div><br></div></div>