[LLVMdev] AliasAnalysis refactoring for the new pass manager

[Chandler Carruth]

Greetings all,

I'm working on refactoring the alias analysis layers to remove the usage of
analysis groups and make the logic sharable between old and new pass
managers, and I have a couple of questions below.

As background, the overall plan that I've discussed with Hal and a few
others previously is as follows:
- Create an AliasAnalysisManager which is provided by a normal analysis
pass.
- Use type erasure to register classes which conform to the core
AliasAnalysis concept with the AliasAnalysisManager.
- The concept will consist solely of the virtual methods currently on
AliasAnalysis -- all the helpers and such will just be directly provided by
the manager layer.

This will make the AA infrastructure look much like the TTI infrastructure,
but much simpler as the AA interface boundary is actually a reasonable and
small concept.

As part of this, there won't be any inheritance relationship between alias
analyses, and so the nested enums currently in the AliasAnalysis base class
aren't a great way of describing the return types of these interfaces. I'd
like to lift them out to be proper top-level enums that describe various
aliasing and mod-ref information. In some ways, I think this is cleaner,
especially for mod-ref information which might reasonably be used in
interfaces that aren't precisely that of AA. Any concerns so far?


Ok, provided you're happy with this, I'd like to ask what names and naming
conventions people like. Here is a straw-man:

enum class AliasKind {
  NoAlias = 0,
  MayAlias,
  PartialAlias,
  MustAlias
};

I find the "Alias" suffix redundant, but "No", "Maybe", "Partial", and
"Must" also seem awkward. Is there a better enum name than "AliasKind"?
These aren't *just* results, so I don't like the current name.

Whatever convention we use, we should use a similar one for the ModRef
stuff. ModRefBehavior there already seems to have good names if it were
switched to an enum class outside of AA. ModRefResult I would probably make
ModRefKind, but maybe ModRefInfo? We call the methods getModRefInfo....

Please suggest patterns that you like!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150613/d7e8f2ce/attachment.html>