That pass also had some debug printing logic in it which I have not at
this time replicated. I'm considering leaving that for folks to add when
the have use cases where it would help rather than trying what wil be
helpful here.
Depends on D12080.
Paths
| Differential D12142
[PM/AA] Flesh out statistics to cover all the primary use cases of the old AliasAnalysisCounter pass. Needs ReviewPublic Authored by chandlerc on Aug 19 2015, 2:40 AM. This revision needs review, but there are no reviewers specified.
Details
Summary That pass also had some debug printing logic in it which I have not at Depends on D12080.
Diff Detail Event Timelinechandlerc retitled this revision from to [PM/AA] Flesh out statistics to cover all the primary use cases of the old AliasAnalysisCounter pass.. chandlerc updated this object. Comment Actions It seems unfortunate to need to make the AA result statistics essentially part of the boilerplate necessary to implement a good AA provider. Can we move all statistics generation into the aggregrator? We don't need to use the STATISTIC macro, really, the aggregrator can construct a set of such objects based on the names of the underlying providers in its care, and then use them as it iterates up the chain. Comment Actions I'm OK working on doing that (I actually started there), but it looked like
Comment Actions
The statistics are important, let's think this through. We need a few things (bikeshedding aside): struct AAStats { Statistic NumAliasQueries; Statistic NumNoAliasResults; ... // Statistics need a const char* description with a matching lifetime. std::string NumAliasQueriesName; std::string NumNoAliasResultsName; ... AAStats(const std::string &PassName) { NumAliasQueriesName = PassName + " 'alias' queries"; NumNoAliasResultsName = PassName + " 'alias' queries resulting in 'NoAlias'"; ... NumAliasQueries.construct(DEBUG_TYPE, NumAliasQueriesName.c_str()); NumNoAliasResults.construct(DEBUG_TYPE, NumNoAliasResultsName.c_str()); ... } }; Then we need some map inside the aggregator, from pass name to these structs, or just keep an array of them in the same order as the AA chain. Regardless, it seems like AAResults::Concept needs a getName() function, or if we keep them in an array (probably better), then addAAResult might need to take a name parameter. Regardless, then we can put all of the stats updating into the AAResults methods. Are there some tricky lifetime issues regarding the statistics objects relative to AAResults? Do these really need to live in the wrapper pass for the legacy pass manager and in AAManager for the new one?
Revision Contents
Diff 32525 include/llvm/Analysis/BasicAliasAnalysis.h
lib/Analysis/AliasAnalysis.cpp
lib/Analysis/BasicAliasAnalysis.cpp
lib/Analysis/GlobalsModRef.cpp
lib/Analysis/ObjCARCAliasAnalysis.cpp
lib/Analysis/ScalarEvolutionAliasAnalysis.cpp
lib/Analysis/ScopedNoAliasAA.cpp
lib/Analysis/TypeBasedAliasAnalysis.cpp
|
Given the check just before the switch (i.e., Result != MayAlias) can the MayAlias case ever be hit?