thr3ads.net - llvm dev - [llvm-dev] GlobalsAA from GVN [Dec 2015]

If this information is useful, please help other people find it:
Share via:

Vaivaswatha Nagaraj via llvm-dev

2015-Dec-03 12:21 UTC

[llvm-dev] GlobalsAA from GVN

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>

Mehdi Amini via llvm-dev

2015-Dec-03 15:51 UTC

head link

[llvm-dev] GlobalsAA from GVN

> On Dec 3, 2015, at 4:21 AM, Vaivaswatha Nagaraj via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> Thank you both for the inputs. I've created a patch for the same,
please review:
> http://reviews.llvm.org/D15185 <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
I don’t expect this: the PassManager should honor the order you insert passes. 
I confirmed with: opt -debug-pass=Structure  -globals-aa -instcombine
-slp-vectorizer -globals-aa -gvn

 ModulePass Manager
    CallGraph Construction
    Globals Alias Analysis
    FunctionPass Manager
      Basic Alias Analysis (stateless AA impl)
      Function Alias Analysis Results
      Dominator Tree Construction
      Combine redundant instructions
      Natural Loop Information
      Scalar Evolution Analysis
      Function Alias Analysis Results
      SLP Vectorizer
    CallGraph Construction
    Globals Alias Analysis
    FunctionPass Manager
      Dominator Tree Construction
      Basic Alias Analysis (stateless AA impl)
      Function Alias Analysis Results
      Memory Dependence Analysis
      Global Value Numbering
      Module Verifier


— 
Mehdi



> , 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
<mailto:hfinkel at anl.gov>> wrote:
> ----- Original Message -----
> > From: "Vaivaswatha Nagaraj via llvm-dev" <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
> > To: "James Molloy" <james at jamesmolloy.co.uk
<mailto:james at jamesmolloy.co.uk>>
> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org
<mailto: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 <mailto: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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 
> _______________________________________________
> 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/b5602caa/attachment.html>

Vaivaswatha Nagaraj via llvm-dev

2015-Dec-03 16:29 UTC

head link

[llvm-dev] GlobalsAA from GVN

Hi Mehdi,

Thank you for the response.

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.

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.

Thanks,

  - Vaivaswatha

On Thu, Dec 3, 2015 at 9:21 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> On Dec 3, 2015, at 4:21 AM, Vaivaswatha Nagaraj via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> 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
>
>
> I don’t expect this: the PassManager should honor the order you insert
> passes.
> I confirmed with: opt -debug-pass=Structure  -globals-aa -instcombine
> -slp-vectorizer -globals-aa -gvn
>
>  ModulePass Manager
>     CallGraph Construction
>     Globals Alias Analysis
>     FunctionPass Manager
>       Basic Alias Analysis (stateless AA impl)
>       Function Alias Analysis Results
>       Dominator Tree Construction
>       Combine redundant instructions
>       Natural Loop Information
>       Scalar Evolution Analysis
>       Function Alias Analysis Results
>       SLP Vectorizer
>     CallGraph Construction
>     Globals Alias Analysis
>     FunctionPass Manager
>       Dominator Tree Construction
>       Basic Alias Analysis (stateless AA impl)
>       Function Alias Analysis Results
>       Memory Dependence Analysis
>       Global Value Numbering
>       Module Verifier
>
>
> —
> Mehdi
>
>
>
>
> , 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
>>
>
> _______________________________________________
> 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/f74245fd/attachment.html>

Reasonably Related Threads

Search for more apparently analagous threads

llvm dev - Dec 2015 - GlobalsAA from GVN

[llvm-dev] GlobalsAA from GVN

[llvm-dev] GlobalsAA from GVN

[llvm-dev] GlobalsAA from GVN

Reasonably Related Threads