Choosing an alias analyzer

Hi,

In lib/Transforms/IPO/PassManagerBuilder.cpp: addInitialAliasAnalysisPasses,
I see this code

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.

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