[LLVMdev] The Trouble with Triples (original) (raw)

Renato Golin renato.golin at linaro.org
Wed Jul 8 08:08:55 PDT 2015

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

More information about the llvm-dev mailing list