llvm dev - Oct 2017 - TargetMachine vs LLVMTargetMachine

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 <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.
- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171002/7435e622/attachment.html>

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

  -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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
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/b1909b55/attachment.html>

On Tue, Oct 3, 2017 at 8:54 AM Hal Finkel via llvm-dev <
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.

-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 listllvm-dev at
lists.llvm.orghttp://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/20171003/795cdc9d/attachment.html>