<div dir="ltr"><div class="gmail_quote"><div>Sorry to not have replied to these high level comments earlier...</div><div><br></div><div dir="ltr">On Sat, Jun 13, 2015 at 3:00 AM Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chandler,<br>
<br>
I wasn't part of the discussion, but as part of other refactorings,<br>
I'd like to make sure we're all following the same design goals.<br></blockquote><div><br></div><div>Pretty sure that all of this is just the same pattern as already discussed many times.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So far, it seems that we're on the same page, but I have some comments inline.<br>
<br>
<br>
On 13 June 2015 at 09:52, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<br>
> - Create an AliasAnalysisManager which is provided by a normal analysis<br>
> pass.<br>
> - Use type erasure to register classes which conform to the core<br>
> AliasAnalysis concept with the AliasAnalysisManager.<br>
> - The concept will consist solely of the virtual methods currently on<br>
> AliasAnalysis -- all the helpers and such will just be directly provided by<br>
> the manager layer.<br>
<br>
I believe this is the design we're going for other such manager<br>
classes, right? Sounds good to me.<br></blockquote><div><br></div><div>Yep. Nothing new here. If anything, this'll be a much better example as the interface isn't so huge.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> As part of this, there won't be any inheritance relationship between alias<br>
> analyses, and so the nested enums currently in the AliasAnalysis base class<br>
> aren't a great way of describing the return types of these interfaces. I'd<br>
> like to lift them out to be proper top-level enums that describe various<br>
> aliasing and mod-ref information.<br>
<br>
I'm all for it. I think we need to keep the interface public and<br>
simple, and the implementation private and as complicated as it has to<br>
be. Also, this doesn't mean we're exposing more information, just that<br>
we're exposing the right things.<br></blockquote><div><br></div><div>Yep.</div></div></div>