<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 15, 2016 at 8:18 PM, 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>"Daniel Berlin" <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>><br><b>To: </b>"Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br><b>Cc: </b><a href="mailto:rsilvera@google.com" target="_blank">rsilvera@google.com</a>, "Chandler Carruth" <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>>, "David Majnemer" <<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>>, "Nicolai Hähnle-Montoro" <<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a>>, "Chad Rosier" <<a href="mailto:mcrosier@codeaurora.org" target="_blank">mcrosier@codeaurora.org</a>>, "llvm-commits" <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>>, <a href="mailto:reviews%2BD9375%2Bpublic%2B6271545f2d8b34dd@reviews.llvm.org" target="_blank">reviews+D9375+public+6271545f2<wbr>d8b34dd@reviews.llvm.org</a><br><b>Sent: </b>Monday, August 15, 2016 10:03:58 PM<span><br><b>Subject: </b>Re: [PATCH] D9375: An llvm.noalias intrinsic<br><br></span><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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><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><br></div><span><div>The one without loop info, can be readnone.</div><div>The with loop info, we figure that out :)</div></span></div></div></div></blockquote></span><span>That sounds great, but I don't have any idea how that would work. </span></div></div></blockquote><span><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)">At the point in time when I insert the intrinsics, I'm either in the inliner or in the frontend, and I don't know anything about loops.</div></div></blockquote><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)">Moreover, I might be inserting the intrinsics into places that won't obviously dominate, or be inside, loops until after inlining.<span style="font-family:arial,sans-serif;font-size:small;color:rgb(34,34,34)"> </span></div></div></blockquote><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)"> Even if I add loop information to the inliner (which we'll want to do anyway), having the inliner each for newly-dominating llvm.noalias intrinsics and fix them up with information about the newly-inserted loops seems asymptotically unfavorable.<br></div></div></blockquote><div><br></div><div>Note that if we do loop info in the inliner, and keep it up to date, you already have all the info you need to fix-them-up, and i guess i don't see what the issue is.</div><div><br>At worst, all you have to do is track what block these things appear in, and when loopinfo determines that block has a loop id, you promote them and give them that loop id...</div><div>When it determines a block no longer has a loop id, you demote them.</div><div>It already has to do all the real work to keep the loops up to date anyway ...<br></div></span></div></div></div></blockquote>Just to be clear, what I'm going to care about is finding intrinsics that dominate a given loop, not those in the loop.</div></div></blockquote><div><br></div><div>Ah. I would have figured you also cared about the intra-iteration intrinsic, and that would have appeared at the start of the loop body, since that is where the restrict scope ends up starting after inlining</div><div><br></div><div><br></div><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)"> So either I need each loop to have some list of dominating intrinsics (i.e. originally dominating, neglecting any hosting that might occur), or each intrinsic needs a list of the loops it originally dominates. It is maintaining this that I was afraid could get expensive. These lists could be filtered by loops only containing some pointer based on the intrinsic (we can probably use a direct use/def check here because omission would be conservatively correct). Is your opinion still the same?</div></div></blockquote><div><br></div><div>Let me see how often we destroy loopinfo.</div><div><br></div><div>The ideal non-loop way to store this is to just augment dominator tree nodes, or store it associated with the dfs numbers in the domtree (which would allow collection for a given loop in O(level depth of dom tree) time, but we definitely destroy that too much.<br></div><div><br></div></div></div></div>