[LLVMdev] Problem Adding New Pass to Alias Analysis Group
John Criswell
criswell at illinois.edu
Wed Jul 10 14:18:33 PDT 2013
Dear All,
I think I just found the problem.
For those interested, only a few methods of the AliasAnalysis class are
virtual; many are non-virtual convenience wrapper that call the virtual
methods. A new alias analysis cannot override the non-virtual methods;
it must override the virtual methods.
As it turns out, my alias analysis (more accurately, the alias analysis
that I'm porting) overrode the non-virtual wrappers and not the virtual
methods, so passes using it would call AliasAnalysis::<wrapperMethod>
which called the AliasAnalysis::<virtualMethod>. I'm guessing the
wrapper methods were virtual in earlier versions of LLVM.
-- John T.
On 7/10/13 4:06 PM, John Criswell wrote:
> On 7/10/13 3:43 PM, Cristianno Martins wrote:
>> Hello John,
>>
>> What opt command line arguments are you using?
>
> I'm not using opt. I'm manually scheduling a pipline within a tool.
> The code looks like this:
>
> PassManager pm;
> MyAlias * aa = new MyAlias();
> pm.add(aa);
> pm.add(new MyAliasUsingPass());
>
> Both MyAlias and MyAliasUsingPass are now ModulePass'es. MyAlias is
> an alias analysis pass while MyAliasUsingPass is a pass that requires
> an alias analysis and performs a test query.
>
> The output of -debug-pass=Structure is the following:
>
> No Alias Analysis (always returns 'may' alias)
> ModulePass Manager
> MyAlias
> MyAliasUsingPass
>
>
> I've changed MyAlias to call abort() when it is queried, but the
> program never crashes when running MyAliasUsingPass, which indicates
> that my MyAlias is never being used for queries.
>
> I've also tried making MyAlias an ImmutablePass, but that didn't
> appear to work either.
>
>>
>> If you follow this link
>> <http://llvm.org/docs/Passes.html#no-aa-no-alias-analysis-always-returns-may-alias>,
>> you can see that -no-aa is the default alias analysis implementation
>> if you do not manually specify which AA passes you want to use. Note
>> that you can pass as many different implementations of AA as you
>> want, and each of them will be chained together for each function,
>> like a pipeline, if the previous one was not able to determine if
>> there is a dependence or not.
>
> Yes, I am aware of how analysis groups are *supposed* to work. :) I'm
> just not getting the advertised functionality and am at a loss as to
> what I could be doing wrong.
>
> -- John T.
>
>>
>> Hope this help,
>>
>>
>>
>> --
>> Cristianno Martins
>> PhD Student of Computer Science
>> University of Campinas
>> cmartins at ic.unicamp.br <mailto:cmartins at ic.unicamp.br>
>>
>>
>> On Wed, Jul 10, 2013 at 1:24 PM, John Criswell <criswell at illinois.edu
>> <mailto:criswell at illinois.edu>> wrote:
>>
>> Dear All,
>>
>> I'm trying to add a new alias analysis to the alias analysis
>> group in LLVM 3.2. This new pass is linked statically into a
>> tool that lives outside the LLVM source tree, so I'm trying to
>> avoid making patches to the LLVM sources.
>>
>> I've added the INITIALIZE_AG_PASS_BEGIN() and
>> INITIALIZE_AG_PASS_END() code to the pass, manually scheduled it
>> before the MemoryDependenceAnalysis pass, and have tried making
>> it a FunctionPass and an ImmutablePass, but no matter what I do,
>> it seems like MemoryDependenceAnalysis and other passes keep
>> using the -no-aa default pass instead.
>>
>> 1) Does anyone have ideas on how to verify that my pass is part
>> of the alias analysis group?
>>
>> 2) Does anyone have any ideas on what I might be doing wrong?
>>
>> Any ideas would be appreciated.
>>
>> Thanks in advance,
>>
>> -- John T.
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>> http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130710/0c581a25/attachment.html>
More information about the llvm-dev
mailing list