[llvm-dev] GlobalsAA from GVN

Thu Dec 3 21:24:10 PST 2015

>You could, in the LTO pipeline, reinsert GlobalsAA after the SLPVectorizer
(not saying you should).
I didn't realise that adding GlobalsAA* after* SLPVectorizer could help.
Thanks for this tip.

>There is something fishy. Do you have a test case that reproduce with
llvm-lto?
I'm currently looking at a proprietary benchmark. I'll try to extract out a
simple test case and send it.

  - Vaivaswatha

On Fri, Dec 4, 2015 at 12:00 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:

>
> On Dec 3, 2015, at 8:29 AM, Vaivaswatha Nagaraj <vn at compilertree.com>
> wrote:
>
> 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.
>
>
> 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).
>
> 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.
>
>
> There is something fishy. Do you have a test case that reproduce with
> llvm-lto?
>
> Thanks,
>
> —
> Mehdi
>
>
>
> 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/20151204/d03d3a3a/attachment.html>