[LLVMdev] AliasAnalysis refactoring for the new pass manager

[David Blaikie]

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


>
> 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/20150613/f413ed5d/attachment.html>