
<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>"Chandler Carruth" <chandlerc@gmail.com><br><b>To: </b>"Hal Finkel" <hfinkel@anl.gov>, "Chandler Carruth" <chandlerc@gmail.com><br><b>Cc: </b>llvm-commits@lists.llvm.org<br><b>Sent: </b>Friday, March 11, 2016 8:07:34 AM<br><b>Subject: </b>Re: [llvm] r263231 - [PM] The order of evaluation of these analyses is actually significant,<br><br><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Mar 11, 2016 at 2:42 PM 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;"><hr id="zwchr"><br>

> From: "Chandler Carruth via llvm-commits" <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>><br>

> To: <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>

> Sent: Friday, March 11, 2016 7:26:48 AM<br>

> Subject: [llvm] r263231 - [PM] The order of evaluation of these analyses is actually significant,<br>

><br>

> Author: chandlerc<br>

> Date: Fri Mar 11 07:26:47 2016<br>

> New Revision: 263231<br>

><br>

> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=263231&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=263231&view=rev</a><br>

> Log:<br>

> [PM] The order of evaluation of these analyses is actually<br>

> significant,<br>

> much to my horror, so use variables to fix it in place.<br>

><br>

> This terrifies me. Both basic-aa and memdep will provide more precise<br>

> information when the domtree and/or the loop info is available.<br>

> Because<br>

> of this, if your pass (like GVN) requires domtree, and then queries<br>

> memdep or basic-aa, it will get more precise results. If it does this<br>

> in<br>

> the other order, it gets less precise results.<br>

><br>

> All of the ideas I have for fixing this are, essentially, terrible.<br>

<br>

I assume that we could delay the calls to getAnalysisIfAvailable until query time, instead of caching the results in runOnFunction. What are the other options?<br></blockquote><div><br></div><div>Requiring these unilaterally.</div><div><br></div><div>I've managed to do that for domtree, no problem.</div><div><br></div><div>The only thing left is LoopInfo for BasicAA. Which is only used to accelerate isPotentiallyReachable inside of loop-y code. The options I see are:</div><div><br></div><div>1) Require it. This doubles the number of times we build loop info (from 5 to 10) in the O2 pipeline.</div><div><br></div><div id="DWT5759">2) Lazily query it. This has some problems, mostly that it is *sloooow*. It'll have to be a query through a type erased callable and then into the getAnalysisIfAvailable code path in the worst case which is multiple more indirect calls. So 2 - 4 layers of function pointer calls would be my guess. On each query. And despite the runtime hit, we continue to have *very* unpredictable behavior, here basic-aa becomes more powerful "magically" when other analyses are still kicking around. This is at least only structural with the current pass manager, but with the new pass manager, a very old cached entry will suddenly empower basic-aa.... Yuck.</div></div></div></blockquote>This is, at least in principle, the same yucky magic we have now. ;) - and I'm not sure what to think about the indirection cost because I'm not under the impression that we make a lot of LI queries. That having been said, I'm fine with delaying fixing this until the new PM is ready as we have a work-around now, and adding this heavier-weight workaround is not clearly an improvement.<br><br> -Hal<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>3) Build a LoopBasicAA pass that was BasicAA but with LoopInfo required, and add it to the pipeline while we have loop info. But this means we'll do 2x the non-Loop BasicAA queries.</div><div><br></div><div>4) Stop using LoopInfo in BasicAA entirely.</div><div><br></div><div>I'm actually a fan of #1, but probably can't justify it until the new PM lands and we can at least stop re-computing the same loop info for the same functions that aren't changing run after run.</div><div><br></div><div>-Chandler</div></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>