[LLVMdev] AliasAnalysis refactoring for the new pass manager

[Chandler Carruth]

Sorry to not have replied to these high level comments earlier...

On Sat, Jun 13, 2015 at 3:00 AM Renato Golin <renato.golin at linaro.org>
wrote:

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

Pretty sure that all of this is just the same pattern as already discussed
many times.


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

Yep. Nothing new here. If anything, this'll be a much better example as the
interface isn't so huge.


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

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