[llvm] r218004 - Add a new pass FunctionTargetTransformInfo. This pass serves as a

[Eric Christopher]

>
>
>> +  virtual const TargetSubtargetInfo *getSubtargetImpl(const Function *)
>> const {
>> +    return getSubtargetImpl();
>>
>
> 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?
>
>
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.


> 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)?
>
>

There are no functional changes in this patch.


> -  void getUnrollingPreferences(Loop *L,
>> +  void getUnrollingPreferences(const Function *F, Loop *L,
>>
>
> 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?).
>
>

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.


> -void PPCTTI::getUnrollingPreferences(Loop *L, UnrollingPreferences &UP)
>> const {
>> -  if (ST->getDarwinDirective() == PPC::DIR_A2) {
>> +void PPCTTI::getUnrollingPreferences(const Function *F, Loop *L,
>> +                                     UnrollingPreferences &UP) const {
>>
>
> 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)
>

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

That said, it doesn't necessarily lose me anything.


> -    void getUnrollingPreferences(Loop *L, const TargetTransformInfo &TTI,
>> +    void getUnrollingPreferences(Loop *L, const
>> FunctionTargetTransformInfo &FTTI,
>>
>
> 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))
>
>

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

Thanks for the thoughts. Any ideas are always welcome :)

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140917/297fd567/attachment.html>