llvm dev - Oct 2012 - [LLVMdev] Choosing an alias analyzer

Hi,

In lib/Transforms/IPO/PassManagerBuilder.cpp: addInitialAliasAnalysisPasses,
I see this code
------
  // Add TypeBasedAliasAnalysis before BasicAliasAnalysis so that
  // BasicAliasAnalysis wins if they disagree. This is intended to help
  // support "obvious" type-punning idioms.
  PM.add(createTypeBasedAliasAnalysisPass());
  PM.add(createBasicAliasAnalysisPass());
}
------

My goal is to use ScalarEvolutionAliasAnalysis in MemoryDependenceAnalysis.
When I do,  getPassName in MemoryDependenceAnalysis (by stepping into
getAnalysisUsage), I get
$39 = 0x399f778 "Basic Alias Analysis (stateless AA impl)" 

To switch to ScalarEvolutionAnalysis, I changed
lib/Transforms/IPO/PassManagerBuilder.cpp: addInitialAliasAnalysisPasses to
call createScalarEvolutionAliasAnalysisPass instead of
createBasicAliasAnalysisPass.
But, when I do getPassName() in MemoryDependenceAnalysis , I get TBAA and
not Scalar Evolution Alias Analysis.

What do I have to do to be able to use SCEV Alias Analysis by using the
clang driver (which seems to populate its passes via PassManagerBuilder.cpp)
?

Thanks,
Pranav
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation

Hi Pranav,
> In lib/Transforms/IPO/PassManagerBuilder.cpp:
addInitialAliasAnalysisPasses,
> I see this code
> ------
>    // Add TypeBasedAliasAnalysis before BasicAliasAnalysis so that
>    // BasicAliasAnalysis wins if they disagree. This is intended to help
>    // support "obvious" type-punning idioms.
>    PM.add(createTypeBasedAliasAnalysisPass());
>    PM.add(createBasicAliasAnalysisPass());
> }
> ------
>
> My goal is to use ScalarEvolutionAliasAnalysis in MemoryDependenceAnalysis.
> When I do,  getPassName in MemoryDependenceAnalysis (by stepping into
> getAnalysisUsage), I get
> $39 = 0x399f778 "Basic Alias Analysis (stateless AA impl)"
>
> To switch to ScalarEvolutionAnalysis, I changed
> lib/Transforms/IPO/PassManagerBuilder.cpp: addInitialAliasAnalysisPasses to
> call createScalarEvolutionAliasAnalysisPass instead of
> createBasicAliasAnalysisPass.
> But, when I do getPassName() in MemoryDependenceAnalysis , I get TBAA and
> not Scalar Evolution Alias Analysis.
>
> What do I have to do to be able to use SCEV Alias Analysis by using the
> clang driver (which seems to populate its passes via
PassManagerBuilder.cpp)
you have to schedule SCEV alias analysis immediately before your pass.  The
problem is that if a pass invalidates alias analysis information, then the
next time a pass that needs alias analysis is run then the pass manager has
to recreate alias analysis, and when it does so the SCEV analysis is not
recreated.  To get around this (which is what is done for TBAA and basic alias
analysis if I remember right), the pass needs to be declared immutable, i.e.
has no state, so is always valid and doesn't need to be destroyed or
recreated.
I doubt this is possible for the SCEV alias analysis, but I didn't look into
it.
Yes, this is all an endless source of pain.  There's a very old PR about it
(PR3703?).

Ciao, Duncan.
> ?
>
> Thanks,
> Pranav
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by
> The Linux Foundation
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Hi Duncan,
> you have to schedule SCEV alias analysis immediately before your pass.
The
> problem is that if a pass invalidates alias analysis information, then the
next
> time a pass that needs alias analysis is run then the pass manager has to
> recreate alias analysis, and when it does so the SCEV analysis is not
> recreated.  To get around this (which is what is done for TBAA and basic
alias
> analysis if I remember right), the pass needs to be declared immutable,
i.e.
> has no state, so is always valid and doesn't need to be destroyed or
> recreated.
> I doubt this is possible for the SCEV alias analysis, but I didn't look
into it.
> Yes, this is all an endless source of pain.  There's a very old PR
about
it
> (PR3703?).
> 
> Ciao, Duncan.
> 
Thanks for the information.

Pranav
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation