[llvm-dev] The Trouble with Triples

Matthew Fortune via llvm-dev
Wed, 23 Sep 2015 22:37:59 -0000

Eric Christopher echristo at gmail.com<mailto: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.

>> 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.)
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.)
Daniel Sanders Daniel.Sanders at imgtec.com<mailto: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.
Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150923/18280adc/attachment.html>