<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 3, 2015, at 9:24 PM, Vaivaswatha Nagaraj <<a href="mailto:vn@compilertree.com" class="">vn@compilertree.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">>You could, in the LTO pipeline, reinsert GlobalsAA after the SLPVectorizer (not saying you should).<br class=""></div>I didn't realise that adding GlobalsAA<i class=""> after</i> SLPVectorizer could help. Thanks for this tip.<br class=""><br class=""><div class="">>There is something fishy. Do you have a test case that reproduce with llvm-lto?</div>I'm currently looking at a proprietary benchmark. I'll try to extract out a simple test case and send it.<br class=""></div></div></blockquote><div><br class=""></div><div>Suggestion: if you get some IR, and bugpoint it (see <a href="http://blog.llvm.org/2015/11/reduce-your-testcases-with-bugpoint-and.html" class="">http://blog.llvm.org/2015/11/reduce-your-testcases-with-bugpoint-and.html</a> ) ; it shouldn’t be anything significant about the original benchmark in the end ;)</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div></div></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature"><div dir="ltr" class=""> - Vaivaswatha<br class=""></div></div></div>
<br class=""><div class="gmail_quote">On Fri, Dec 4, 2015 at 12:00 AM, Mehdi Amini <span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Dec 3, 2015, at 8:29 AM, Vaivaswatha Nagaraj <<a href="mailto:vn@compilertree.com" target="_blank" class="">vn@compilertree.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">Hi Mehdi, <br class=""><br class="">Thank you for the response.<br class=""><br class="">I'm actually on an LTO setup and was referring to PassManagerBuilder::addLTOOptimizationPasses. Here, GlobalsAA is scheduled to run well ahead of SLPVectorizer. However since GlobalsAA is a module pass, it runs once and a bunch of passes, including SLPVectorizer is run for each function. When one of them invalidates the analysis, rest of the functions do not have it available. Both LICM and GVN face the same issue. <br class=""><br class=""></div></div></div></div></blockquote><div class=""><br class=""></div></span>I was reacting to the fact that you claimed that you can’t reinsert a Module pass between two function passes, which is not true. You could, in the LTO pipeline, reinsert GlobalsAA after the SLPVectorizer (not saying you should).</div><div class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Surprisingly I didn't see this issue on release37. In fact, on an LTO setup, more LICMs happen on release37 than on the latest SVN, for many of the benchmarks, just because of this.<br class=""></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">There is something fishy. Do you have a test case that reproduce with llvm-lto?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div><div class="">— </div><span class="HOEnZb"><font color="#888888" class=""><div class="">Mehdi</div></font></span><div class=""><div class="h5"><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div>Thanks,<br class=""></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class=""><div dir="ltr" class=""> - Vaivaswatha<br class=""></div></div></div>
<br class=""><div class="gmail_quote">On Thu, Dec 3, 2015 at 9:21 PM, Mehdi Amini <span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Dec 3, 2015, at 4:21 AM, Vaivaswatha Nagaraj via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">Thank you both for the inputs. I've created a patch for the same, please review:<br class=""><a href="http://reviews.llvm.org/D15185" target="_blank" class="">http://reviews.llvm.org/D15185</a><br class=""><br class="">><span class=""></span>You can specifically insert it into the pass pipeline, but in this case, we should just fix SLP to preserve the analysis.<br class=""></div>@Hal, I tried doing this but it didn't seem to work. I added the GlobalsAA pass right before GVN but it didn't seem to help. In retrospect, looking at the way pass manager works, it looks like it wasn't of much use. Since GlobalsAA is a ModulePass, and FunctionPasses that are scheduled even later are run first</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I don’t expect this: the PassManager should honor the order you insert passes. </div><div class="">I confirmed with: opt -debug-pass=Structure -globals-aa -instcombine -slp-vectorizer -globals-aa -gvn</div><div class=""><br class=""></div><div class=""> ModulePass Manager<br class=""> CallGraph Construction<br class=""> Globals Alias Analysis<br class=""> FunctionPass Manager<br class=""> Basic Alias Analysis (stateless AA impl)<br class=""> Function Alias Analysis Results<br class=""> Dominator Tree Construction<br class=""> Combine redundant instructions<br class=""> Natural Loop Information<br class=""> Scalar Evolution Analysis<br class=""> Function Alias Analysis Results<br class=""> SLP Vectorizer<br class=""> CallGraph Construction<br class=""> Globals Alias Analysis<br class=""> FunctionPass Manager<br class=""> Dominator Tree Construction<br class=""> Basic Alias Analysis (stateless AA impl)<br class=""> Function Alias Analysis Results<br class=""> Memory Dependence Analysis<br class=""> Global Value Numbering<br class=""> Module Verifier<br class=""><br class=""></div><div class=""><br class=""></div><div class="">— </div><span class=""><font color="#888888" class=""><div class="">Mehdi</div></font></span><div class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">, those FunctionPasses that invalidate it do so for good. I do not know if there is some other way to force it though.<br class=""><br class=""></div>Thanks,<br class=""></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class=""><div dir="ltr" class=""> - Vaivaswatha<br class=""></div></div></div>
<br class=""><div class="gmail_quote">On Thu, Dec 3, 2015 at 4:53 PM, Hal Finkel <span dir="ltr" class=""><<a href="mailto:hfinkel@anl.gov" target="_blank" class="">hfinkel@anl.gov</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br class="">
> From: "Vaivaswatha Nagaraj via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>><br class="">
> To: "James Molloy" <<a href="mailto:james@jamesmolloy.co.uk" target="_blank" class="">james@jamesmolloy.co.uk</a>><br class="">
> Cc: "LLVM Dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>><br class="">
> Sent: Thursday, December 3, 2015 5:20:34 AM<br class="">
> Subject: Re: [llvm-dev] GlobalsAA from GVN<br class="">
><br class="">
> Hi James,<br class="">
><br class="">
> Thanks for the help. From the log, I could infer that SLP vectorizer<br class="">
> is not preserving alias analysis, preventing GVN from getting the<br class="">
> info. Although the first function to get compiled has GlobalsAA<br class="">
> available during GVN, rest of them do not as SLP vectorizer run on<br class="">
> that function invalidates GlobalsAA which is a module pass. Is there<br class="">
> a way to force re-computation of a particular analysis?<br class="">
<br class="">
</span>You can specifically insert it into the pass pipeline, but in this case, we should just fix SLP to preserve the analysis.<br class="">
<br class="">
-Hal<br class="">
<div class=""><div class=""><br class="">
><br class="">
> As a side note, I didn't have this problem on release_37.<br class="">
><br class="">
> Thanks a lot.<br class="">
><br class="">
> Regards,<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> - Vaivaswatha<br class="">
><br class="">
><br class="">
> On Thu, Dec 3, 2015 at 3:02 PM, James Molloy <<br class="">
> <a href="mailto:james@jamesmolloy.co.uk" target="_blank" class="">james@jamesmolloy.co.uk</a> > wrote:<br class="">
><br class="">
><br class="">
><br class="">
> Hi Vaivaswatha,<br class="">
><br class="">
><br class="">
> GlobalsAA is not an immutable pass because it needs to cache queries<br class="">
> to avoid them being unusably slow. It therefore relies on passes<br class="">
> explicitly preserving it. Most of the passes in the scalar pipeline<br class="">
> have been modified to setPreserved<GlobalsAA>() and I know the pass<br class="">
> gets preserved at least until LICM.<br class="">
><br class="">
><br class="">
> You can use -debug-pass=Executions to determine at what point<br class="">
> GlobalsAA is not preserved (which pass clobbers it) - you'd then<br class="">
> need to add GlobalsAA to its preserved pass list.<br class="">
><br class="">
><br class="">
> Cheers,<br class="">
><br class="">
><br class="">
> James<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> On Wed, 2 Dec 2015 at 09:35 Vaivaswatha Nagaraj via llvm-dev <<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a> > wrote:<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> Hi,<br class="">
><br class="">
> I've noticed that alias analysis queries arising from GVN do not use<br class="">
> the results from GlobalsAA.<br class="">
> The last call to AAResultsWrapperPass::runOnFunction() before GVN<br class="">
> does not add GlobalsAAWrapperPass due to unavailability. This leads<br class="">
> to the alias queries from GVN not having any globals mod-ref info.<br class="">
><br class="">
> Is this a known issue? and is there any way to have globals mod-ref<br class="">
> info available for GVN?<br class="">
><br class="">
> Thanks,<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> - Vaivaswatha<br class="">
> _______________________________________________<br class="">
> LLVM Developers mailing list<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
><br class="">
><br class="">
> _______________________________________________<br class="">
> LLVM Developers mailing list<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
><br class="">
<br class="">
</div></div><span class=""><font color="#888888" class="">--<br class="">
Hal Finkel<br class="">
Assistant Computational Scientist<br class="">
Leadership Computing Facility<br class="">
Argonne National Laboratory<br class="">
</font></span></blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></div></blockquote></div></div></div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div></div></div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>