[llvm-dev] GlobalsAA from GVN

Vaivaswatha Nagaraj via llvm-dev llvm-dev at lists.llvm.org
Thu Dec 3 23:58:23 PST 2015 

Thank you for the suggestion. I'll try that.

  - Vaivaswatha

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

>
> On Dec 3, 2015, at 9:24 PM, Vaivaswatha Nagaraj <vn at compilertree.com>
> wrote:
>
> >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.
>
>
> Suggestion: if you get some IR, and bugpoint it (see
> http://blog.llvm.org/2015/11/reduce-your-testcases-with-bugpoint-and.html
> ) ; it shouldn’t be anything significant about the original benchmark in
> the end ;)
>
> —
> Mehdi
>
>
>
>
>
>   - 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/502ab8e2/attachment.html>

More information about the llvm-dev mailing list