[LLVMdev] AliasAnalysis refactoring for the new pass manager

[Duncan P. N. Exon Smith]

> On 2015-Jun-13, at 09:12, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Sat, Jun 13, 2015 at 12:52 AM, Chandler Carruth <chandlerc at gmail.com> wrote:
> 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.
> 
> AliasRelationship? None, May/PossiblyAliased/Unknown, Aliased, PartiallyAliased?
> 
> (tense could use some tweaking and I suppose this still has the suffix problem in all except the "None" case... )

I like this colour:

    enum class AliasKind /* or AliasCategory? */ {
      Null,
      Unknown,
      Partial,
      Complete
    };


> 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!
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev