[LLVMdev] AliasAnalysis refactoring for the new pass manager

Duncan P. N. Exon Smith
Mon, 15 Jun 2015 22:53:04 -0000

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