<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">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">----- Original Message -----<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>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><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>