[llvm-dev] The Trouble with Triples

[Eric Christopher via llvm-dev]

On Wed, Sep 23, 2015 at 3:38 PM Matthew Fortune <Matthew.Fortune at imgtec.com>
wrote:

> Eric Christopher echristo at gmail.com writes:
> > Long time no hear :)
>
>
> Indeed. I try to keep quiet as I have a nasty tendency to get involved in
> too many things.
>
>
>
*looks at how many email threads he's in*

Yep. Totally understand :)


>
> >> If I want to use clang as simply as I use GCC what do I need to change
> in llvm/clang to create a compiler such that I can replace ‘gcc’ above with
> ‘clang’ and get the same effect?
>
> > 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 :)
>
> I wouldn’t impose autoconf on anyone who has escaped it. As long as we
> have a route to push this information into a build that is fine. Several
> CMAKE variables would do the same thing. That change seems like a
> no-brainer and could potentially be done in parallel to fixing how the
> information then goes on to flow through LLVM. (If autoconf based builds
> are still alive in LLVM I could try and coach someone through how to do
> this in autoconf but if it is dying in LLVM then let’s not feed it.)
>
I can also coach them through. But yes, this is exactly what should happen.

> The only other part of this is to deal with the concept of the vendor
> triple which I assume there would be no objection to having these
> essentially do what the CMAKE controls would do and update the
> TargetMachine to set up the right defaults. I’d hope all this eventually
> means the ‘triple’ object would become mostly unused except as a method of
> initialising the more detailed information in the target machine and when
> it is needed because it appears in a path. Whatever uses triple today would
> then consult individual pieces of information in the TargetMachine instead.
> (As before I don’t think we need dwell on this here though but instead
> begin discussion about enhancing TargetMachine to start with and then
> inventing MCTargetMachine.)
>

Yep. My baseline is "canonicalize the triple as much as you can coming in,
it'll save you some parsing later, otherwise just query the TargetMachine".


> Daniel Sanders Daniel.Sanders at imgtec.com writes:
>
> 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.
>
> Only the compiler driver is impacted by customised meanings of triples. It
> is a JIT’s responsibility to know what it is targeting and if that needs to
> match the host compiler then that information needs to be extracted from
> the pre-processor breadcrumbs available when compiling the JIT driver
> itself which describe the options the JIT driver is being built with; these
> then have to be translated into TargetMachine settings. A JIT won’t know
> what triple to use let alone the other data without taking it from its own
> build environment. For disassemblers a similar story applies the
> information needs to be taken from the ELF though this time and anything
> missing is a failing of the MIPS ELF format which would need extending to
> carry the information. .MIPS.abiflags helps massively here though.
>

Yep. :)

-eric


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