<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Larisse Voufo" <lvoufo@gmail.com><br><b>To: </b>"Hal Finkel" <hfinkel@anl.gov><br><b>Cc: </b>"Chandler Carruth" <chandlerc@gmail.com>, reviews+D15124+public+ddba332c127856cb@reviews.llvm.org, "llvm-commits" <llvm-commits@lists.llvm.org><br><b>Sent: </b>Wednesday, January 27, 2016 8:39:10 AM<br><b>Subject: </b>Re: [PATCH] D15124: Use @llvm.invariant.start/end intrinsics to extend the meaning of basic AA's pointsToConstantMemory(), for GVN-based load elimination purposes [Local objects only]<br><br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 4:14 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><br><hr><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><span class=""><b>From: </b>"Larisse Voufo" <<a href="mailto:lvoufo@gmail.com" target="_blank">lvoufo@gmail.com</a>><br><b>To: </b>"Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br><b>Cc: </b>"Chandler Carruth" <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>>, <a href="mailto:reviews%2BD15124%2Bpublic%2Bddba332c127856cb@reviews.llvm.org" target="_blank">reviews+D15124+public+ddba332c127856cb@reviews.llvm.org</a>, "llvm-commits" <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>><br></span><b>Sent: </b>Monday, January 25, 2016 5:47:42 PM<div><div class="h5"><br><b>Subject: </b>Re: [PATCH] D15124: Use @llvm.invariant.start/end intrinsics to extend the meaning of basic AA's pointsToConstantMemory(), for GVN-based load elimination purposes [Local objects only]<br><br><div dir="ltr">I have put together a short document to (hopefully) help keep this conversation concise:<div><br></div><div><a href="https://docs.google.com/document/d/1R-gINRdpxzLy82EZK_ymnVNyOPO-tzW5ksNcHuRvxBs/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1R-gINRdpxzLy82EZK_ymnVNyOPO-tzW5ksNcHuRvxBs/edit?usp=sharing</a><br></div><div><br></div><div>Let's see what you think of it. Comments (on the doc) welcome.</div><div><br></div><div>I'll reply to all the other comments (not addressed in the doc) below</div><div><br></div><div>Thanks,</div><div>-- Larisse.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 15, 2016 at 9:55 AM, Larisse Voufo <span dir="ltr"><<a href="mailto:lvoufo@gmail.com" target="_blank">lvoufo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div>Disclaimer: It's a bit hard for me to follow the different "legs" in this conversation. So I'm likely to miss some important background info. But I'll try my best, starting with this one question below.</div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><span>On Wed, Jan 13, 2016 at 3:17 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><br><hr><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Chandler Carruth" <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>><br><b>To: </b>"Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>, "Chandler Carruth" <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>><br><b>Cc: </b><a href="mailto:reviews%2BD15124%2Bpublic%2Bddba332c127856cb@reviews.llvm.org" target="_blank">reviews+D15124+public+ddba332c127856cb@reviews.llvm.org</a>, "Larisse Voufo" <<a href="mailto:lvoufo@gmail.com" target="_blank">lvoufo@gmail.com</a>>, "llvm-commits" <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>><br><b>Sent: </b>Wednesday, January 13, 2016 4:27:13 AM<span><br><b>Subject: </b>Re: [PATCH] D15124: Use @llvm.invariant.start/end intrinsics to extend the meaning of basic AA's pointsToConstantMemory(), for GVN-based load elimination purposes [Local objects only]<br><br></span><div><div><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" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); 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></div></div></blockquote></div></div></blockquote></span><div>It all boils down to solving the following problem:</div><div><br></div><div><b>Given all the tracked invariant_start and invariant_end calls in a given InvariantInfo instance, implement the following function:</b></div><div><br></div><div><div> /// \brief Performs invariant range analysis for some given instruction,</div><div> /// based on some allocated memory address:</div><div> // If the instruction accesses the given address, then this checks whether</div><div> /// there is an invariant range (over the address) that the instruction</div><div> /// belongs in.</div><div> /// NOTE: Range analysis must be enabled for this computation to go through.</div><div><b> bool queriedFromInvariantRange(const Instruction *I, const Value *Addr);</b></div></div><div> </div><div>The test cases in the patch show different combinations of load instructions and (nested) invariant ranges where some loads are merged together while other can't.</div><div><br></div><div>When all instructions share the same block, that's easy. One can simply check that:</div><div>* the invariant_start dominates the instruction and that</div><div>* the instruction dominates the invariant_end.</div><div><br></div><div>The real challenge is when one considers all instructions being nested in complex ways, some of which have been highlighted here, and to try and generalize the solution to all possible case scenari. Unless we limit the cases that we care about, I find it hard to conceive a way of getting around computing (once) and reusing both dominance and post-dominance info. </div><div>In practice, I do not see it getting all that expensive if we keep the effects localized like they are on this patch.</div><div><div><div><br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div><div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); 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).</blockquote></div></div></div></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div>Correct. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div><div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Regarding invariant_end, we need to make sure that no paths from the invariant_start to the load pass through an invariant_end.</blockquote></div></div></div></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div>This is a bit tricky (see attached doc). <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div><div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> For this, it seems conservatively correct to check that the load dominates the invariant_end (or all invariant_ends, should there be multiple), </blockquote></div></div></div></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div>This would not handle nested invariant regions consistently (see doc).</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div><div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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></div></div></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div>Post-dom is the only way to handle general cases consistently, and it does not cost anything more than using dominance analysis (if done right). </div></div></div></div></div></div></blockquote><br>I agree that post-dominance is not more expensive than dominance if done right. It would be really nice to make that true for us in practice. However, we need to be careful here because this is not really a post-dominance problem. As I mentioned in the other reply, just using post-dominance here will cause us to miss the early-exit case.</div></div></blockquote><div><br></div><div id="DWT19377">Please remind me which early exit case you are talking about? (Side note -- We need a better mechanism for managing these threads... :])</div></div></div></div></blockquote><br>invariant_start<br> |<br> load<br> |<br> br<br> / \<br> ret ...<br> |<br> invariant_end<br> ...<br><br>The invariant_end does not post-dominate the load, but the load should be considered to be of constant data. This is the simple early-exit case ;)<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><span class=""><br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div><div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"></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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); 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></div></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div>If we are conservative about where we allow invariant ranges to be open (cf. doc), Neither load #1, nor load #2 should be considered invariant here. Load #1 is dominated by invariant_start, but not post-dominated by the invariant_end. Load#2, in turn is dominated by invariant_start, but also not post-dominated by invariant_end. There is no guarantee of consistent optimizations here (as inner blocks are merged into outer blocks etc...) So, we should not be optimizing these.</div><div><br></div><div>If however, there were no invariant_end at all, then we can safely assume the range open and thus consider the loads invariant.</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div><div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Maybe we need a dedicated CFG walk to collect the necessary information?<br></blockquote></div></div></div></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div>I'm curious. What would this do, and how cheaply, that we wouldn't do with postdom or the dom alternatives?</div></div></div></div></blockquote><br></span>It would check the necessary condition directly. It would walk all paths from the load to the exit, stopping when finding blocks with invariant_exit, previously-visited blocks, exits, or when some search limit is reached. This is obviously not the ideal solution, solving the data-flow problem would be better.<div><div class="h5"><br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div><div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"></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></div></div></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote><div>I think a lot of this is already handled in InvariantInfo.</div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);">This works if there's only one start. If there are multiple starts, then we need only the set to dominate, not any individual one.<br><br>invariant_start invariant_start<br> | |<br> |________________ |<br> |<br> load<br> |<br> ret<br></div></div></blockquote></div></div></div></div></div></blockquote><div><br></div><div>These inner invariant_start should have no effect on the outer load. </div><div>Invariant_ends are defined in terms of invariant_starts, and Invariant_ranges do not extend beyond the scope on invariant_starts. So, I think this case is not relevant (at least for now).</div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><br>At least in theory, this is fine too. The "right" way to solve this might be to set it up as a lattice/dataflow problem on the CFG, and then iterate until convergence (which should happen in two iterations, aside perhaps from pathological cases). The tricky part here, I suspect, is actually the representation (you can't actually build a large map covering (all pointers x all loads), and then prune it). Aside from that, you mark all live-in pointers to all blocks as invariant, except for the entry block, and at the instructions that define the pointer value, and then iterate the system, accounting for the invariant_start/end intrinsics, and you should find the maximal fixed point. The result would be a map of which pointers are invariant at which loads (which, as mentioned, you'd need to represent intelligently). Doing this might actually be faster than locally walking the CFG many times anyway.<br><br>Here's another test case:<br><br>invariant_start<br>____|<br>| |<br>| load<br>| |<br>| invariant_end<br>|____|<br> |<br> ret<br><br>Here, we can't treat the load as invariant, because there's a path from the invariant_start passing through the invariant_end via the loop backedge.</div></div></blockquote></div></div></div></div></div></blockquote><div>This sounds like is a case for nested invariant regions in the doc (?)...</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><span><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_quote"><div></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></div></blockquote></span></div></div></blockquote></div></div></div></div></div></blockquote><div>I am not exactly how this makes a difference, performance-wise. But then again, any sound implementation of queriedFromInvariantRange() would do...</div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);">GVN already scans the entire (reachable) function body (and, by an order of magnitude, is dominated by the cost of AA queries). I doubt we'll notice. That having been said, we can avoid the linear scan if we use a registration approach for these intrinsics, just as we did with @llvm.assume (the AssumptionCache).<br></div></div></blockquote></div></div></div></div></div></blockquote><div><br></div><div>The invariant-range-analysis pass and other (InvariantInfo-related passes) are doing this.</div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><br>Another issue worth considering:<br><br> entry<br> ___________|_____<br> | |<br>invariant_start invariant_start<br> | |<br> load load<br> | |<br> ... ...<br><br>Generally, we'd PRE this load (adding it to the entry block). Either the invariant_start will block this (which is bad), or we'll want to also PRE the invariant_starts to avoid PRE killing the invariant info.</div></div></blockquote></div></div></div></div></div></blockquote><div><br></div><div>I don't see how this is possible. Invariant intrinsics are ignored by basic AA except for when invariant range analysis is computed.</div></div></div></div></blockquote><br></div></div>You don't see how what is possible? The fact that the intrinsics are ignored by BasicAA is precisely why we'd want to PRE the intrinsics along with the loads.</div></div></blockquote><div><br></div><div>I am scanning through the implementation of GVN::performPRE(), and it is not clear to me how having an invariant_start before a load prevents the load from being PRE'd. Besides, have you looked at the <a href="https://docs.google.com/spreadsheets/d/19W1167l9QFrXMXccX4-cValmC5EtlFfUbT7Tr3xaoJs/edit?usp=sharing#gid=1063925865" target="_blank">comparative stats</a> I linked earlier? We actually get a <b>10% increase on the number of loads PRE'd</b>. </div><div id="DWT19376"><br></div></div></div></div></blockquote><br>Right, I'm not complaining about that ;) -- I'm saying that, when we do PRE the loads, if they're arranged as I indicated above, *after* the loads are PRE'd, we've lost the information on the const-ness of the loaded data. Have you checked the configuration I sketched above? I imagine that we'll get an increase in PRE'd loads from loads all dominated by the same invariant_start, in which case this is not a concern.<br><br>Thanks again,<br>Hal<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><span class="HOEnZb"><font color="#888888"><br><br> -Hal</font></span><span class=""><br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><span><font color="#888888"><br><br> -Hal</font></span><span><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_quote"><div></div><div><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); 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>
</blockquote><br><br><br>-- <br><div><span></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span></span><br></div></span></div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>
</blockquote><br><br><br>-- <br><div><span></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span></span><br></div></span></div></div></blockquote></div><br></div></div>
</blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>