[llvm-dev] TargetMachine vs LLVMTargetMachine

[Hal Finkel via llvm-dev]

On 10/03/2017 04:42 PM, Eric Christopher wrote:
>
>
> On Tue, Oct 3, 2017 at 2:37 PM Hal Finkel <hfinkel at anl.gov 
> <mailto:hfinkel at anl.gov>> wrote:
>
>
>     On 10/03/2017 04:30 PM, Eric Christopher wrote:
>>
>>
>>     On Tue, Oct 3, 2017 at 8:54 AM Hal Finkel via llvm-dev
>>     <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>>
>>         On 10/02/2017 10:57 PM, Matthias Braun via llvm-dev wrote:
>>>         The distinction between the LLVMTargetMachine and
>>>         TargetMachine classes has become somewhat muddy recently. So
>>>         I created:
>>>
>>>         https://reviews.llvm.org/D38482
>>>
>>>         to clean things up. During review it was noted that we may
>>>         rather merge the two instead which looks like this:
>>>
>>>         https://reviews.llvm.org/D38489
>>>
>>>         We really should choose one of the two over the status quo.
>>>         Some points for the discussion:
>>>
>>>         - I am not aware of any target that is actually implementing
>>>         TargetMachine only but not LLVMTargetMachine (I assume the C
>>>         backend used to do it before it was removed)
>>>         - Even when merging the two, I believe it is still possible
>>>         to implement a target without linking to lib/CodeGen by
>>>         returning nullptr for the various methods related to CodeGen.
>>
>>         If this is true, then it seems like we don't lose anything
>>         from doing this (and the code gets cleaner). We don't
>>         currently have anything in tree that
>>
>>
>>     This was my suggestion of yesterday.
>>
>>         motivates the current split. It does seem useful to retain
>>         the ability to have a direct-from-the-IR backend (mostly for
>>         translation into another IR).
>>
>>
>>     I'm dubious of this need, but as long as it doesn't add any
>>     overhead to the resultant code I'm good.
>
>     The other thing that I asked in the other review thread, which
>     I'll repeat here, is: does GlobalISel further reduce the
>     motivation for this? The primary reason, as I understand it, for
>     needing this kind of "direct" translation is to avoid going
>     through type legalization. This can be important for software
>     targeting FPGAs, for example, because the hardware can deal with
>     arbitrary bit widths. With GlobalISel, can you go into CodeGen
>     effectively without any legalization and then go on from there (if
>     one needed such a thing)?
>
>
> Not right now, no.

Okay.

> That said I'm uncertain how much we particularly care about keeping 
> two classes here when we can just change how initialization works to 
> provide nullptr versions of the local bits rather than having a 
> separate overhead class.

I agree. I'm already sold on merging them. Having to provide functions 
returning nullptr seems like a small overhead.

  -Hal

>
> -eric
>
>      -Hal
>
>
>>
>>     -eric
>>
>>          -Hal
>>
>>
>>>         - The split would give some notion of an internal CodeGen
>>>         interface and an external interface visible to
>>>         frontend/middleend etc.
>>>         - The code gets simpler when merging the two and we have to
>>>         document/explain less.
>>>
>>>         - Matthias
>>>
>>>
>>>         _______________________________________________
>>>         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
>>
>>         -- 
>>         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
>>
>
>     -- 
>     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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/46cf701d/attachment.html>