[LLVMdev] The Trouble with Triples

[Daniel Sanders]

> -----Original Message-----
> From: Renato Golin [mailto:renato.golin at linaro.org]
> Sent: 08 July 2015 16:09
> To: Daniel Sanders
> Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu); Eric Christopher
> (echristo at gmail.com); Jim Grosbach (grosbach at apple.com)
> Subject: Re: The Trouble with Triples
> 
> On 8 July 2015 at 15:31, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
> > The first reason is that compiler options can overrule the triple but leave
> > it unchanged. For example, in GCC mips-linux-gnu-gcc normally produces
> > 32-bit MIPS-I output using the O32 ABI, but 'mips-linux-gnu-gcc –mips64'
> > normally produces 64-bit MIPS-III output using the N32 ABI. Like GCC,
> > compiler options to mips-linux-gnu-clang should (and mostly do but MIPS
> has
> > a few crashing cases caused by triple misuse) overrule the triple. However,
> > we don't mutate the triple to reflect this so any decisions based on the
> > overridable state cannot rely on the triple to accurately reflect the
> > desired behaviour.
> 
> Another very annoying fact is that the Clang driver re-parses triples
> many times, and sometimes they change the triple based on a CPU, and
> then end up with a different CPU.
> 
> There was a bug that if you passed "thumbv7", it would not recognise,
> pick "ARM7TDMI" CPU, and later change the triple to "armv4t" because
> of that, and pass *that* to the internal processes (GAS, IAS, linker).
> 
> This bug has been fixed by adding "thumb" to it, but the underlying
> reason it happened means there are plenty of other similar bugs
> waiting to happen. We need to fix the mechanism in which we understand
> targets, and having an unambiguous description that spans across *all*
> LLVM projects (including Clang, LLD, LLDB) and tools (llc, lli,
> llvm-mc, etc) is the ultimate goal.
> 
> Most targets do not have those problems, but Mips and ARM are a big
> mess. That's why we're so interested in making that happen.

This reminded me of something I noticed in passing and haven't investigated yet. I think TargetRegistry::lookupTarget(const std::string &ArchName, Triple&, std::string&) can do this kind of thing when ArchName is a registered architecture but is not understood by Triple::getArchTypeForLLVMName(). I haven't had chance to try it but it looks like you'd get the intended target architecture without updating the triple to match (so x86_64-linux-gnu could target a completely different architecture).

> > This configure-by-source-patch approach seems to make
> > some people uncomfortable so we may have to find another way to
> configure
> > the triples (tablegen?).
> 
> Another option that would make *all* distributions happy would be to
> adopt the same approach as GCC and have CMake options for default ABI
> choices.
> 
> This would be harder to implement, but we can hide the mess under a
> separate class (TargetABI?). I actually prefer this solution to either
> tablegen or patch-sets.

I can see a way to make the CMake option approach work nicely for native. The constructor can check for the default triple and apply the effects of the CMake options to it. I don't think there's a good way to support the multiple triples or heterogenous use cases via CMake options but support for that was more a happy coincidence rather than intentional design.

If we take this route, I'm hoping I don't need to do autoconf since I don't know it very well.

> > a.       Maintain backwards compatibility with IR using triples, at least
> > for a while.
> 
> Probably forever... :(
> 
> Again, this can be isolated in TargetABI or some other place.

As far as I know there is no backwards compatibility promise, but equally it doesn't seem reasonable to give no notice before removing it. I'm therefore thinking that we can deprecate it in one release (3.7 or 3.8), then remove it in the next.