[llvm-dev] The Trouble with Triples

[Daniel Sanders via llvm-dev]

> > As I understand it your proposal aims to help solve the issue of getting the complete
> > set of ABI information to every part of LLVM that needs it and you are saying
> > TargetMachine should encapsulate that data directly.
> Essentially. To be more precise I'm saying that TargetMachine (or an MC level equivalent
> - see TargetSubtargetInfo/MCSubtargetInfo) should encapsulate everything that's needed
> from the object level down for any particular target.

That sounds like TargetTuple but spelt something like MCTargetMachine. It sounds like MCTargetMachine should usurp the Triple in the places it exists in the MC layer (and maybe be introduced to a few new portions of it) and accurately reflect the desired target just like in the later stages of the TargetTuple plan intended. The main difference I see is small a small subset of the fields can be removed because they aren't needed in the MC layer and we may end up with more than one TargetTuple-like object (one for each major aspect of LLVM).

I'm wondering if this point has been one big communication failure.

> > My perspective on ‘the trouble with triples’:
> > Given you have a GNU background I’ll pose a scenario in GCC config parlance and perhaps you
> > can explain how, if at all, you see LLVM responding to the issue. This is a fake scenario but is still
> > representative of what happens in the real world.
> <snip>
> Right now this isn't completely possible. I agree that it should be and I personally imagine this as being done via toolchain
> configuring to set defaults at the clang level. We already do some of this for target, I just see it adding more to that sort
> of configuration (whether or not done via autoconf is completely orthogonal of course :)

The question I want to ask here is: What about API users? Things like JIT's and debuggers will want the same defaults (possibly augmented by auto-detection). One nice thing about handling this in the Triple/TargetTuple boundary was that these users get the same behaviour as clang in all areas of LLVM.

> b) The lack of a TargetMachine at the MC level was something I brought up a long time ago in
> this thread with my proposed solutions. This is what needs to be fixed, especially given that targets
> can switch ISA, ABI, floating point, etc within a single assemble action.

This is somewhat off-topic but just for my own knowledge. When you say 'ABI' here do you mean the register names or the wider ABI? I'm aware we can change register names but I don't think we can change the actual ABI on the fly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150923/e4a2f7ad/attachment.html>