[llvm-dev] The Trouble with Triples

Wed Sep 23 15:37:59 PDT 2015

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>