[LLVMdev] AliasAnalysis refactoring for the new pass manager

[John Criswell]

Dear Chandler,

A few questions:

1) Are you removing the analysis groups functionality?  If so, will the 
new way to get similar functionality be to write a Manager pass like 
AliasAnalysisManager?

2) Will AliasAnalysis passes still chain as they do today?

3) Will your refactoring fix the "problem" (or maybe it's a feature?) of 
having to manually schedule AliasAnalysis passes because pass 
invalidation always causes the default AliasAnalysis pass from the group 
to be scheduled by the PassManager?

We have some old code that, if we resurrect it, will need to be 
rewritten if Analysis Groups are removed.  Removing/Replacing Analysis 
Groups is fine, but I'd like to know in advance if they disappear.

Regards,

John Criswell

On 6/13/15 2: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.
>
> 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


-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

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