[LLVMdev] The Trouble with Triples

[Renato Golin]

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


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


> Renato: This has been revised slightly from the last one we discussed due to
> public C++ API's being used internally as well as externally.

Roger.

I'd also wanted to add the TargetParser changes and how this all fit
into the plan.

TargetParser is a target-specific class that knows how to parse
strings and convert to platform choices (and back) in a way that is
both unambiguous and ubiquitous.

Meaning, all tools and projects should use the TargetParser to
understand what are the platform specific options, what do they mean
and how are they related to each other.

The TargetTuple is the perfect companion, since we can use the
TargetParser to understand triples, cpu/fpu names, extensions, etc,
and related them inside the Tuple in an ABI-specific way (via the ABI
modifiers).

Right now, both Clang and LLVM ARM assembler are using the
ARMTargetParser, but the idea is to expand this to the Triple when
TargetTuple beings Daniel's plan step #4 onwards.

We'll probably have a MIPSTargetParser, too. And probably refactor the
hierarchy of that, to make sure we can get polymorphism and so on. But
I wanted to keep-it-simple-and-stupid before we had a reason not to.


> I understand from Renato that there are more threads over the last few years
> but I haven't looked for them.

There were numerous discussions about the driver complicated
structure, never-ending bugs, parsing mismatches and triple
shenanigans over the last 5 years. I couldn't possibly link all of
them here. :)

Specifically between Mips and ARM, I think me and Reed had a few
specific discussions a few years ago, but I can't seem to find them.
That was probably 2010/2011.

cheers,
--renato