<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
+  virtual const TargetSubtargetInfo *getSubtargetImpl(const Function *) const {<br>
+    return getSubtargetImpl();<br></blockquote><div><br></div></div></div><div>So what's left to do to make this actually do the real work of picking a Subtarget based on the Function? I'm just curious about where that'll fit in your migration plan?<br><br></div></div></div></div></blockquote><div><br></div><div>I was going to fix up all of the occurrences of getting a subtarget without a function first and then actually pick the function. That gives me a bunch of no functional change patches to get everything going.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Once this function is actually implemented, would it be possible to test just this one change (& then test each subsequent feature as you port it over)? </div><div><div class="h5"><div> </div></div></div></div></div></div></blockquote><div><br></div><div>There are no functional changes in this patch.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-  void getUnrollingPreferences(Loop *L,<br>
+  void getUnrollingPreferences(const Function *F, Loop *L,<br></blockquote><div><br></div></div></div><div>Would it make more sense for this to take the TargetSubtargetInfo directly? A more constrained API (makes it clear what this function is using - just the subtarget info, not other things with the Function) and potentially fewer Subtarget lookups (which are zero cost today, but later will become at least some kind of map lookup/lazy construction/etc?).</div><div><div class="h5"><div> </div></div></div></div></div></div></blockquote><div><br></div><div>Possibly. I thought about limiting it here, but the problem is that each particular target could have it's own desires and I was hoping for a more uniform API. It's definitely something that could be adjusted though.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-void PPCTTI::getUnrollingPreferences(Loop *L, UnrollingPreferences &UP) const {<br>
-  if (ST->getDarwinDirective() == PPC::DIR_A2) {<br>
+void PPCTTI::getUnrollingPreferences(const Function *F, Loop *L,<br>
+                                     UnrollingPreferences &UP) const {<br></blockquote><div><br></div></div></div><div>And in places like this, if you passed the Subtarget, you could even call it "ST" and then the body of the function wouldn't need any changes at all. (granted, shadowing is subtle stuff... so I can understand if that's not ideal - but given the ultimate future will end up removing the member variable, it might be an acceptable intermediate state to reduce typing/churn)</div></div></div></div></blockquote><div><br></div><div>Right. And this would be why it might work. I.e. instead of Function, take Subtarget since that'll be what everything uses ultimately to get the various target data structures. I have no ultimate preference here other than I will likely have to cast that subtarget no matter what to be the type of the actual TargetSubtargetInfo that the target wants (I.e. PPCSubtargetInfo).</div><div><br></div><div>That said, it doesn't necessarily lose me anything.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-    void getUnrollingPreferences(Loop *L, const TargetTransformInfo &TTI,<br>
+    void getUnrollingPreferences(Loop *L, const FunctionTargetTransformInfo &FTTI,<br></blockquote><div><br></div></div></div><div>Hmm - might chat to you offline to better understand the relationship between a Target and a TargetTransformInfo and a Subtarget and the FunctionTargetTransformInfo (the proto-question forming in my head is "why not move the Function-requiring operations to the FunctionTargetTransformInfo (& have the FTTI use a Subtarget member, rather than a Function member passed down into the TTI)"... probably lots of good reasons that I know nothing about))</div><div><div class="h5"><div> </div></div></div></div></div></div></blockquote><div><br></div><div>This goes into the reasons why I hate the pass manager. I can do it that way (modulo the casting above), but then we'd have to have every target implement both a TargetTransformInfo and a FunctionTargetTransformInfo rather than just forwarding (unless I've missed something about your question).</div><div> </div><div>Thanks for the thoughts. Any ideas are always welcome :)</div><div><br></div><div>-eric</div></div></div></div>