Hi James, Thanks for the help. From the log, I could infer that SLP vectorizer is not preserving alias analysis, preventing GVN from getting the info. Although the first function to get compiled has GlobalsAA available during GVN, rest of them do not as SLP vectorizer run on that function invalidates GlobalsAA which is a module pass. Is there a way to force re-computation of a particular analysis? As a side note, I didn't have this problem on release_37. Thanks a lot. Regards, - Vaivaswatha On Thu, Dec 3, 2015 at 3:02 PM, James Molloy <james at jamesmolloy.co.uk> wrote:> Hi Vaivaswatha, > > GlobalsAA is not an immutable pass because it needs to cache queries to > avoid them being unusably slow. It therefore relies on passes explicitly > preserving it. Most of the passes in the scalar pipeline have been modified > to setPreserved<GlobalsAA>() and I know the pass gets preserved at least > until LICM. > > You can use -debug-pass=Executions to determine at what point GlobalsAA is > not preserved (which pass clobbers it) - you'd then need to add GlobalsAA > to its preserved pass list. > > Cheers, > > James > > On Wed, 2 Dec 2015 at 09:35 Vaivaswatha Nagaraj via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> I've noticed that alias analysis queries arising from GVN do not use the >> results from GlobalsAA. >> The last call to AAResultsWrapperPass::runOnFunction() before GVN does >> not add GlobalsAAWrapperPass due to unavailability. This leads to the alias >> queries from GVN not having any globals mod-ref info. >> >> Is this a known issue? and is there any way to have globals mod-ref info >> available for GVN? >> >> Thanks, >> >> - Vaivaswatha >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151203/eb539a10/attachment.html>
Hi, The SLP Vectorizer doesn't introduce or modify globals so it should preserve GlobalsAA. That it doesn't sounds like a bug. James On Thu, 3 Dec 2015 at 11:20 Vaivaswatha Nagaraj <vn at compilertree.com> wrote:> Hi James, > > Thanks for the help. From the log, I could infer that SLP vectorizer is > not preserving alias analysis, preventing GVN from getting the info. > Although the first function to get compiled has GlobalsAA available during > GVN, rest of them do not as SLP vectorizer run on that function invalidates > GlobalsAA which is a module pass. Is there a way to force re-computation of > a particular analysis? > > As a side note, I didn't have this problem on release_37. > > Thanks a lot. > > Regards, > > - Vaivaswatha > > On Thu, Dec 3, 2015 at 3:02 PM, James Molloy <james at jamesmolloy.co.uk> > wrote: > >> Hi Vaivaswatha, >> >> GlobalsAA is not an immutable pass because it needs to cache queries to >> avoid them being unusably slow. It therefore relies on passes explicitly >> preserving it. Most of the passes in the scalar pipeline have been modified >> to setPreserved<GlobalsAA>() and I know the pass gets preserved at least >> until LICM. >> >> You can use -debug-pass=Executions to determine at what point GlobalsAA >> is not preserved (which pass clobbers it) - you'd then need to add >> GlobalsAA to its preserved pass list. >> >> Cheers, >> >> James >> >> On Wed, 2 Dec 2015 at 09:35 Vaivaswatha Nagaraj via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi, >>> >>> I've noticed that alias analysis queries arising from GVN do not use the >>> results from GlobalsAA. >>> The last call to AAResultsWrapperPass::runOnFunction() before GVN does >>> not add GlobalsAAWrapperPass due to unavailability. This leads to the alias >>> queries from GVN not having any globals mod-ref info. >>> >>> Is this a known issue? and is there any way to have globals mod-ref info >>> available for GVN? >>> >>> Thanks, >>> >>> - Vaivaswatha >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151203/3f39ce05/attachment.html>
----- Original Message -----> From: "Vaivaswatha Nagaraj via llvm-dev" <llvm-dev at lists.llvm.org> > To: "James Molloy" <james at jamesmolloy.co.uk> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 5:20:34 AM > Subject: Re: [llvm-dev] GlobalsAA from GVN > > Hi James, > > Thanks for the help. From the log, I could infer that SLP vectorizer > is not preserving alias analysis, preventing GVN from getting the > info. Although the first function to get compiled has GlobalsAA > available during GVN, rest of them do not as SLP vectorizer run on > that function invalidates GlobalsAA which is a module pass. Is there > a way to force re-computation of a particular analysis?You can specifically insert it into the pass pipeline, but in this case, we should just fix SLP to preserve the analysis. -Hal> > As a side note, I didn't have this problem on release_37. > > Thanks a lot. > > Regards, > > > > > > - Vaivaswatha > > > On Thu, Dec 3, 2015 at 3:02 PM, James Molloy < > james at jamesmolloy.co.uk > wrote: > > > > Hi Vaivaswatha, > > > GlobalsAA is not an immutable pass because it needs to cache queries > to avoid them being unusably slow. It therefore relies on passes > explicitly preserving it. Most of the passes in the scalar pipeline > have been modified to setPreserved<GlobalsAA>() and I know the pass > gets preserved at least until LICM. > > > You can use -debug-pass=Executions to determine at what point > GlobalsAA is not preserved (which pass clobbers it) - you'd then > need to add GlobalsAA to its preserved pass list. > > > Cheers, > > > James > > > > > On Wed, 2 Dec 2015 at 09:35 Vaivaswatha Nagaraj via llvm-dev < > llvm-dev at lists.llvm.org > wrote: > > > > > > > > > Hi, > > I've noticed that alias analysis queries arising from GVN do not use > the results from GlobalsAA. > The last call to AAResultsWrapperPass::runOnFunction() before GVN > does not add GlobalsAAWrapperPass due to unavailability. This leads > to the alias queries from GVN not having any globals mod-ref info. > > Is this a known issue? and is there any way to have globals mod-ref > info available for GVN? > > Thanks, > > > > > > > > > - Vaivaswatha > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
Thank you both for the inputs. I've created a patch for the same, please review: http://reviews.llvm.org/D15185>You can specifically insert it into the pass pipeline, but in this case,we should just fix SLP to preserve the analysis. @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, those FunctionPasses that invalidate it do so for good. I do not know if there is some other way to force it though. Thanks, - Vaivaswatha On Thu, Dec 3, 2015 at 4:53 PM, Hal Finkel <hfinkel at anl.gov> wrote:> ----- Original Message ----- > > From: "Vaivaswatha Nagaraj via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "James Molloy" <james at jamesmolloy.co.uk> > > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > > Sent: Thursday, December 3, 2015 5:20:34 AM > > Subject: Re: [llvm-dev] GlobalsAA from GVN > > > > Hi James, > > > > Thanks for the help. From the log, I could infer that SLP vectorizer > > is not preserving alias analysis, preventing GVN from getting the > > info. Although the first function to get compiled has GlobalsAA > > available during GVN, rest of them do not as SLP vectorizer run on > > that function invalidates GlobalsAA which is a module pass. Is there > > a way to force re-computation of a particular analysis? > > You can specifically insert it into the pass pipeline, but in this case, > we should just fix SLP to preserve the analysis. > > -Hal > > > > > As a side note, I didn't have this problem on release_37. > > > > Thanks a lot. > > > > Regards, > > > > > > > > > > > > - Vaivaswatha > > > > > > On Thu, Dec 3, 2015 at 3:02 PM, James Molloy < > > james at jamesmolloy.co.uk > wrote: > > > > > > > > Hi Vaivaswatha, > > > > > > GlobalsAA is not an immutable pass because it needs to cache queries > > to avoid them being unusably slow. It therefore relies on passes > > explicitly preserving it. Most of the passes in the scalar pipeline > > have been modified to setPreserved<GlobalsAA>() and I know the pass > > gets preserved at least until LICM. > > > > > > You can use -debug-pass=Executions to determine at what point > > GlobalsAA is not preserved (which pass clobbers it) - you'd then > > need to add GlobalsAA to its preserved pass list. > > > > > > Cheers, > > > > > > James > > > > > > > > > > On Wed, 2 Dec 2015 at 09:35 Vaivaswatha Nagaraj via llvm-dev < > > llvm-dev at lists.llvm.org > wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > I've noticed that alias analysis queries arising from GVN do not use > > the results from GlobalsAA. > > The last call to AAResultsWrapperPass::runOnFunction() before GVN > > does not add GlobalsAAWrapperPass due to unavailability. This leads > > to the alias queries from GVN not having any globals mod-ref info. > > > > Is this a known issue? and is there any way to have globals mod-ref > > info available for GVN? > > > > Thanks, > > > > > > > > > > > > > > > > > > - Vaivaswatha > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151203/6c2c822e/attachment.html>