<div dir="ltr"><div>John,</div><div><br></div><div>Below is some information for posterity, we have a workaround for our OOT target and, as I've been told today in the Alias Analysis monthly meeting, the new pass manager doesn't have this problem.</div><div><br></div><div>Thank you for your suggestion but unfortunately, adding PhiValues as dependency to either GVN or MemDep won't solve the problem. Analysis passes such as BasicAA have two stages of living:</div><div><br></div><div>1. During the runOnFunction method, and<br></div><div>2. Querying time.</div><div><br></div><div>The decision of whether PhiValues available for BasicAA is made during the first phase:</div><div><br></div><div>bool BasicAAWrapperPass::runOnFunction(Function &F) {</div><div> auto *PV = getAnalysisIfAvailable<PhiValuesWrapperPass>();</div><div><br></div><div>During querying time, BasicAA checks if PhiValues is available:</div><div><br></div><div>bool BasicAAResult::alias(Function &F) {</div><div> if (PV)</div><div> // Use PhiValues</div><div> else</div><div> // Fall back to simpler heuristics</div><div><br></div><div>Given the following pass order:</div><div><br></div><div>Basic Alias Analysis</div><div>Function Alias Analysis</div><div>MergedLoadStoreMotion</div><div>Phi Values Analysis</div><div>Function Alias Analysis</div><div>Memory Dependence Analysis</div><div>...</div><div>Global Value Numbering</div><div><br></div><div>BasicAA is run as a prerequisite to MergedLoadStoreMotion and it happens *not* to have PhiValues available. MergedLoadStoreMotion preserves BasicAA, so runOnFunction is not run again before GVN, so when GVN queries BasicAA, BasicAA doesn't have access to PhiValues.</div><div><br></div><div>A workaround suggested at the Alias Analysis meeting, is to add a dummy pass before GVN whose sole purpose is to invalidate BasicAA.</div><div><br></div><div>Thanks everybody for their help,<br></div><div>Alexey<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 30, 2021 at 12:19 PM John Brawn <<a href="mailto:John.Brawn@arm.com">John.Brawn@arm.com</a>> wrote:<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 dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
>From what I remember, and from looking at the code, the way things are supposed to work is:</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
* GVN uses MemoryDependenceAnalysis</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
* MemoryDependenceAnalysis has PhiValuesWrapperPass as a required dependency</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
* The alias analysis used by <span style="background-color:rgb(255,255,255);display:inline">MemoryDependenceAnalysis therefore makes use of PhiValuesWrapperPass</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="background-color:rgb(255,255,255);display:inline"><br>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="background-color:rgb(255,255,255);display:inline">I don't remember if the alias analysis used by MemoryDependenceAnalysis also getting and</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="background-color:rgb(255,255,255);display:inline">using the result of PhiValuesWrapperPass was an intended consequence of this or not.</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="background-color:rgb(255,255,255);display:inline">Possibly it would make sense for GVN to directly require PhiValuesWrapperPass, which may</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="background-color:rgb(255,255,255);display:inline">fix the problem.</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="background-color:rgb(255,255,255);display:inline"><br>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<span style="background-color:rgb(255,255,255);display:inline">John</span></div>
<div>
<div id="gmail-m_887329553252507769appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_887329553252507769divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Alexey Zhikhartsev <<a href="mailto:alexey.zhikhar@gmail.com" target="_blank">alexey.zhikhar@gmail.com</a>><br>
<b>Sent:</b> 27 April 2021 19:15<br>
<b>To:</b> via Llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Cc:</b> John Brawn <<a href="mailto:John.Brawn@arm.com" target="_blank">John.Brawn@arm.com</a>>; <a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a> <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>><br>
<b>Subject:</b> BasicAA depending on PhiValues analysis</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>Hi all,</div>
<div><br>
</div>
<div>I encountered a problem where an optimization that uses BasicAA is very fragile due to BasicAA's "weak" reliance on the PhiValues analysis.</div>
<div><br>
</div>
<div>The whole story is this: our team is in the process of upgrading to the newest version of LLVM, and I discovered that on the newest LLVM, Global Value Numbering doesn't apply an important optimization anymore.</div>
<div><br>
</div>
<div>A little bit of background: GVN depends on Basic Alias Analysis, and BasicAA depends on PhiValues. However, the dependence between GVN and AA is "strong":</div>
<div><br>
</div>
<div> getAnalysis<AAResultsWrapperPass>().getAAResults()</div>
<div><br>
</div>
<div>Whereas between BasicAA and PhiValues it is "weak" (note "IfAvailable"):</div>
<div><br>
</div>
<div><span> auto</span> *PVWP = getAnalysisIfAvailable<PhiValuesWrapperPass>();</div>
<div><br>
</div>
<div>So, in the old LLVM, BasicAA that runs before GVN, happens to find cached PhiValues analysis, gives good results to GVN, and GVN applies the optimization. But on the new LLVM, BasicAA doesn't have PhiValues, gives poor results to GVN, and GVN gives up.
It looks to me that whether BasicAA gets its hands on PhiValues is almost entirely up to chance, which makes the clients of BasicAA very fragile, meaning that it's hard to be sure if an optimization you need will get applied.</div>
<div><br>
</div>
<div>I see the discussion in <a href="https://reviews.llvm.org/D44564" target="_blank">https://reviews.llvm.org/D44564</a> but I'm pretty much out of my depth there and I'm not sure if a solution to the problem above has been mentioned.</div>
<div><br>
</div>
<div>Maybe the new pass manager has this problem solved?</div>
<div><br>
</div>
<div>Anyhow, I would appreciate any input, thank you in advance.</div>
<div><br>
</div>
<div>Best,</div>
<div>Alex<br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</blockquote></div>