This is an archive of the discontinued LLVM Phabricator instance.

[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

Reviewers
None
Summary

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.

Diff Detail

Event Timeline

chandlerc updated this revision to Diff 32525.Aug 19 2015, 2:40 AM
chandlerc 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.
chandlerc added a subscriber: llvm-commits.
mcrosier added inline comments.
lib/Analysis/AliasAnalysis.cpp
109

Given the check just before the switch (i.e., Result != MayAlias) can the MayAlias case ever be hit?

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.

I'm OK working on doing that (I actually started there), but it looked like
I'd need to do a fair amount of work and it will slow me down... How badly
do you want this now, and how much do you want to put it on my critical
path to moving forward? I don't have strong opinions here, I'm jsut looking
for the fastest way to make forward progress.

I'm OK working on doing that (I actually started there), but it looked like
I'd need to do a fair amount of work and it will slow me down...

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?

How badly
do you want this now, and how much do you want to put it on my critical
path to moving forward? I don't have strong opinions here, I'm jsut looking
for the fastest way to make forward progress.