[llvm-dev] The Trouble with Triples

[Eric Christopher via llvm-dev]

On Wed, Sep 23, 2015 at 3:26 PM Daniel Sanders <Daniel.Sanders at imgtec.com>
wrote:

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

Right. So I agree with some of this and not with others.

a) Right now we have an is-a relationship between TargetSubtargetInfo and
MCSubtargetInfo as I mentioned in an earlier mail. I really really don't
like it, but changing it out is complicated. I think it'll be interesting
to see how this goes with MCTargetMachine.

b) I don't necessarily think it should usurp the Triple in the MC layer,
but rather perform as an extra layer between MCSubtargetInfo and the rest
of the assembler interface.

c) I think we'll only want one MCTargetMachine for any invocation of
clang/llvm-mc/etc. It should be able to mode switch (via MCSubtargetInfos
possibly?) when necessary (e.g. .set mips3) similar to how TargetMachine
does at the IR level.


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

I think so? :)


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

JIT users already have to construct the TargetMachine. As do debugger
users. A JIT user should be configuring as they'd like to execute things
without (possibly) taking into account what the surrounding binary is doing
(as you can have interprocess jitting anyhow). A debugger should,
theoretically at least, be using the ELF flags of the target binary. If
something can't be represented there we'll generally use a section of flags
if I recall what we did with gcc when we needed to pass extraneous data
around.


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

Wider ABI, i.e. something like .set fpmath= could change the ABI for
surrounding functions. I'm... disappointed at how that works in the ELF
flags case, but it might be less of an issue.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150923/eb0f5102/attachment.html>