[LLVMdev] AliasAnalysis refactoring for the new pass manager

[Philip Reames]

On 06/13/2015 12:52 AM, Chandler Carruth 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.
I would mildly prefer that the current (or similar) element names are 
kept.  A lot of the literature talks about may alias and must alias 
relationships, so I'd prefer to stick with consistent and known 
terminology.  I'm specificly worried about the readabity of code in 
places like MemoryDependenceAnalysis and GVN for newcomers to the 
community.

AliasKind::Must is less clear to me than AlaisKind::MustAlias.  The 
second is admittedly more verbose, but that's not always a bad thing.


>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150615/c97c68e4/attachment.html>