<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Aug 4, 2016 at 12:32 AM Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">silvas added a comment.<br>
<br>
In <a href="https://reviews.llvm.org/D21462#505454" rel="noreferrer" target="_blank">https://reviews.llvm.org/D21462#505454</a>, @chandlerc wrote:<br>
<br>
> > I hear your argument (IIRC we discussed this at a social) about back pointers being somewhat annoying, but the ability to use just a `void*` to represent the information passed to an analysis makes it much easier to have a unified analysis manager.<br>
><br>
><br>
> I don't think I understand the connection you see between up pointers and using a 'void*' to represent the information passed to an analysis. Can you re-explain this? Sorry if it just isn't clicking for me....<br>
><br>
> That said, in general I would like to not sacrifice type safety because of concerns around mapping arguments from one interface to another though.<br>
<br>
<br>
The issue is that for a unified analysis manager, AnalysisPassConcept is not templated (on IRUnitT and couldn't be on the ExtraArgTs). Therefore, we need to pass a type-erased object through its `run` method. Currently, the type-erased IRUnit can be passed as a void*, and then the AnalysisPassModel (which *is* templated on IRUnitT) just casts it back since it knows the right type.<br>
At least with the current registration stuff, all we need right now for type-safety is tracking which IRUnit it is (and there are 4 discrete values which is easy to track).<br>
<br>
Or to put it another way, the ideas you are running with in this patch is very intimately tied to having the analysis manager templated on the signature of the associated `run` method for analyses it manages. A unified analysis manager (which seems like it was the agreed upon design for solving dependency tracking)</blockquote><div><br></div><div>There was no agreement to this. I specifically said I don't at this point agree with that approach, and that I think it is too soon to try to design that approach.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> must type-erase the information you have baked into the template arguments of AnalysisPassConcept here.<br>
At least with the way that the registration stuff works now, you would need to find a way to type-erase the exact signature of the `run` method in order to get type-safety.<br></blockquote><div><br></div><div>Much of this is why I don't agree with the design.</div><div><br></div><div>I'm happy to actually work on a solution to the problem, but right now I'm in large part waiting on review of these patches.</div><div><br></div><div>If in fact we need to go back and type erase things we can always create a new patch to move in that direction.</div></div></div>