[PATCH] D38482: TargetMachine: Use LLVMTargetMachine in CodeGen

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D38482#886622, @chandlerc wrote:

> In https://reviews.llvm.org/D38482#886613, @MatzeB wrote:
>
> > In https://reviews.llvm.org/D38482#886520, @chandlerc wrote:
> >
> > > 2. If in #1 you mean actual targets -- are there any left now that the C backend is gone? What are these targets? I wonder if we could simplify things by collapsing a no longer necessary layer.
> >
> >
> > - There is none in open source, and I don't know of any internal ones at my company.
> > - According to the mailing list this may be good for SPIR-V (http://lists.llvm.org/pipermail/llvm-dev/2017-June/114593.html) which doesn't really need any of the CodeGen infrastructure.
> > - Indeed collapsing the two classes would slightly simplify the code, and I'd be perfectly fine with that.
> > - On the other hand it's kinda neat to have a CodeGen internal interface with `LLVMTargetMachine` and an outside interface with `TargetMachine`
>
>
> I think we should probably just merge these.
>
> My understanding is that the consensus from the entire community was that SPIR-V really should be leveraging the same common legalization infrastructure as the rest of the targets. Notably, other highly abstract targets like WebAssembly seem to be succeeding with that model.
>
> If we want to introduce a target that doesn't share the core LLVM code generation layer, I'm actually still open to that, but I don't think we should maintain unnecessary abstractions waiting for that day to arrive. I think that sets up the right incentives: if we're going to go down the path of splitting out interfaces in this way, that comes with a cost and we should evaluate that cost against the benefit it provides to those actual use cases. Otherwise it seems too easy to endlessly invent arguments on one side or the other because they are all hypothetical.
>
> But this is always a judgement call, so of course I'm interested in where others see this. It seems like Eric is largely agreeing. Quentin? Craig? Hal? Others?


I think we should ask about this on llvm-dev. Are there other out-of-tree targets where it's still useful to have direct lowering of the IR? Does Emscripten use this? We might check with the folks from Intel/Xilinx re: their FPGA backends. Another aspect of this is that the motivation for doing this may be going away: You used to need to do this in order to get lowering without legalization (or, perhaps register allocation). We now have virtual-register-only backends. With Global ISel, can we get lowering without legalization at all?


Repository:
  rL LLVM

https://reviews.llvm.org/D38482