llvm dev - Dec 2017 - RFC: Exposing TargetTransformInfo factories from TargetMachine

On Fri, Dec 15, 2017 at 5:30 AM, Hal Finkel <hfinkel at anl.gov>
wrote:
> Are there reasons why we might not want to do this? Other options we should
> consider?
It does make the TargetMachine -> TargetIRAnalysis path less abstract,
but given that all targets have the same pattern of instantiating a
TargetIRAnalysis with a Function->TargetTransformInfo hook, the
abstraction does not seem particularly useful.

I might do even a simpler form of the patch though -- instead of
returning a function pointer from TargetMachine, just add a virtual
function to TargetMachine that creates the TargetTransformInfo
directly from a Function.

-- Sanjoy
>
>  -Hal
>
>>
>> [0]:  XLA is a machine learning focussed linear algebra compiler
>> https://www.tensorflow.org/performance/xla/ that uses LLVM for its CPU
>> and GPU backends.
>>
>> -- Sanjoy
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>

On 12/15/2017 12:12 PM, Sanjoy Das wrote:
> On Fri, Dec 15, 2017 at 5:30 AM, Hal Finkel <hfinkel at anl.gov>
wrote:
>> Are there reasons why we might not want to do this? Other options we
should
>> consider?
> It does make the TargetMachine -> TargetIRAnalysis path less abstract,
> but given that all targets have the same pattern of instantiating a
> TargetIRAnalysis with a Function->TargetTransformInfo hook, the
> abstraction does not seem particularly useful.
I agree.
>
> I might do even a simpler form of the patch though -- instead of
> returning a function pointer from TargetMachine, just add a virtual
> function to TargetMachine that creates the TargetTransformInfo
> directly from a Function.
Okay.

  -Hal
>
> -- Sanjoy
>
>>   -Hal
>>
>>> [0]:  XLA is a machine learning focussed linear algebra compiler
>>> https://www.tensorflow.org/performance/xla/ that uses LLVM for its
CPU
>>> and GPU backends.
>>>
>>> -- Sanjoy
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> --
>> Hal Finkel
>> Lead, Compiler Technology and Programming Languages
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

Instead, is there any reason why TTI for a given Subtarget shouldn't live
on the Subtarget? Just construct it the same way we do TargetLowering, etc?

-eric

On Fri, Dec 15, 2017 at 10:13 AM Sanjoy Das via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Fri, Dec 15, 2017 at 5:30 AM, Hal Finkel <hfinkel at anl.gov>
wrote:
> > Are there reasons why we might not want to do this? Other options we
> should
> > consider?
>
> It does make the TargetMachine -> TargetIRAnalysis path less abstract,
> but given that all targets have the same pattern of instantiating a
> TargetIRAnalysis with a Function->TargetTransformInfo hook, the
> abstraction does not seem particularly useful.
>
> I might do even a simpler form of the patch though -- instead of
> returning a function pointer from TargetMachine, just add a virtual
> function to TargetMachine that creates the TargetTransformInfo
> directly from a Function.
>
> -- Sanjoy
>
> >
> >  -Hal
> >
> >>
> >> [0]:  XLA is a machine learning focussed linear algebra compiler
> >> https://www.tensorflow.org/performance/xla/ that uses LLVM for its
CPU
> >> and GPU backends.
> >>
> >> -- Sanjoy
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
> > --
> > Hal Finkel
> > Lead, Compiler Technology and Programming Languages
> > Leadership Computing Facility
> > Argonne National Laboratory
> >
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171219/777ad99d/attachment.html>

I think that would make a lot of sense and avoid a lot of the complicated code.
Though I think I’d rather see a function in TargetMachine taking a const
Function argument, rather than a SubtargetInfo function[1] (you can still
implement the TargetMachine function via a sub target function behind the scenes
of course).

- Matthias

[1] At least seeing that the SubtargetInfo has a number of lib/CodeGen specific
interfaces in it so it had to be moved to include/llvm/CodeGen I’d rather not
see it is used in code outside lib/CodeGen or lib/Target.
> On Dec 18, 2017, at 6:26 PM, Eric Christopher via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Instead, is there any reason why TTI for a given Subtarget shouldn't
live on the Subtarget? Just construct it the same way we do TargetLowering, etc?
> 
> -eric
> 
> On Fri, Dec 15, 2017 at 10:13 AM Sanjoy Das via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> On Fri, Dec 15, 2017 at 5:30 AM, Hal Finkel <hfinkel at anl.gov
<mailto:hfinkel at anl.gov>> wrote:
> > Are there reasons why we might not want to do this? Other options we
should
> > consider?
> 
> It does make the TargetMachine -> TargetIRAnalysis path less abstract,
> but given that all targets have the same pattern of instantiating a
> TargetIRAnalysis with a Function->TargetTransformInfo hook, the
> abstraction does not seem particularly useful.
> 
> I might do even a simpler form of the patch though -- instead of
> returning a function pointer from TargetMachine, just add a virtual
> function to TargetMachine that creates the TargetTransformInfo
> directly from a Function.
> 
> -- Sanjoy
> 
> >
> >  -Hal
> >
> >>
> >> [0]:  XLA is a machine learning focussed linear algebra compiler
> >> https://www.tensorflow.org/performance/xla/
<https://www.tensorflow.org/performance/xla/> that uses LLVM for its CPU
> >> and GPU backends.
> >>
> >> -- Sanjoy
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >
> >
> > --
> > Hal Finkel
> > Lead, Compiler Technology and Programming Languages
> > Leadership Computing Facility
> > Argonne National Laboratory
> >
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171219/39d4466e/attachment.html>

On Mon, Dec 18, 2017 at 6:26 PM, Eric Christopher <echristo at gmail.com>
wrote:
> Instead, is there any reason why TTI for a given Subtarget shouldn't
live on
> the Subtarget? Just construct it the same way we do TargetLowering, etc?
Then stuff that depends on Analysis today will have to depend on
CodeGen, which is probably not ideal.

I think I'll go with Matthias' idea -- remove the function pointer
indirection altogether, and instead just have a virtual
getTargetTransformInfo(Function&) in TargetMachine.

I was also wondering if it makes sense to make the llvm::Function
argument optional -- that'll help make XLA's use case slightly cleaner
since we don't (yet) have per-function target attributes.

-- Sanjoy
>
> -eric
>
>
> On Fri, Dec 15, 2017 at 10:13 AM Sanjoy Das via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> On Fri, Dec 15, 2017 at 5:30 AM, Hal Finkel <hfinkel at anl.gov>
wrote:
>> > Are there reasons why we might not want to do this? Other options
we
>> > should
>> > consider?
>>
>> It does make the TargetMachine -> TargetIRAnalysis path less
abstract,
>> but given that all targets have the same pattern of instantiating a
>> TargetIRAnalysis with a Function->TargetTransformInfo hook, the
>> abstraction does not seem particularly useful.
>>
>> I might do even a simpler form of the patch though -- instead of
>> returning a function pointer from TargetMachine, just add a virtual
>> function to TargetMachine that creates the TargetTransformInfo
>> directly from a Function.
>>
>> -- Sanjoy
>>
>> >
>> >  -Hal
>> >
>> >>
>> >> [0]:  XLA is a machine learning focussed linear algebra
compiler
>> >> https://www.tensorflow.org/performance/xla/ that uses LLVM for
its CPU
>> >> and GPU backends.
>> >>
>> >> -- Sanjoy
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> llvm-dev at lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >
>> >
>> > --
>> > Hal Finkel
>> > Lead, Compiler Technology and Programming Languages
>> > Leadership Computing Facility
>> > Argonne National Laboratory
>> >
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev