[LLVMdev] AliasAnalysis refactoring for the new pass manager

[Renato Golin]

Hi Chandler,

I wasn't part of the discussion, but as part of other refactorings,
I'd like to make sure we're all following the same design goals.

So far, it seems that we're on the same page, but I have some comments inline.


On 13 June 2015 at 09:52, Chandler Carruth <chandlerc at gmail.com> wrote:
> - 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.

I believe this is the design we're going for other such manager
classes, right? Sounds good to me.


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

I'm all for it. I think we need to keep the interface public and
simple, and the implementation private and as complicated as it has to
be. Also, this doesn't mean we're exposing more information, just that
we're exposing the right things.


> I find the "Alias" suffix redundant, but "No", "Maybe", "Partial", and
> "Must" also seem awkward.

I kind of like it, even if it's redundant. Though, I wouldn't use
"MaybeAlias", but "MayAlias", but that's as much as I'd change.

> Is there a better enum name than "AliasKind"?

Well, we're using this pattern everywhere, I think we should just stick to it.

Having said that, I'm not in favour of bike shedding, so I'm fine with
whatever people are more comfortable with.

cheers,
--renato