[LLVMdev] The Trouble with Triples

Renato Golin renato.golin at linaro.org
Fri Jul 31 14:16:04 PDT 2015

On 31 July 2015 at 21:10, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
> This turns out to be very difficult to fix since the majority of the Mips
> target is using Triple::mips and Triple::mips64 to make assumptions about
> the architecture (e.g. are registers 64 bit?) or the ABI (Triple::mips
> implies O32, Triple::mips64 implies N64 or, in cases where this has been
> partially fixed, N32/N64). Unfortunately, in many of these cases the triple
> is the best information I have. At this point, I've hit this wall and seen
> misuse of triples in code reviews enough times that my desire to find a
> general solution to this is very high. I also know of some impending work
> that it likely to make matters worse. I want to be able to, for example, ask
> the TargetTuple whether I am targeting a 64-bit ISA and whether I'm supposed
> to treat it as a 32-bit ISA (e.g. O32 on MIPS64R2) in many areas of LLVM
> (including those where MipsSubtarget and similar are not available) and be
> able to rely on the answer. At the moment, we incorrectly conflate 'is it a
> 64-bit ISA?' with 'is the CPU 64-bit?' as well as 'is the ABI 64-bit?' with
> 'is the ISA 64-bit?'

I feel your pain. We have our own variants of VFP, PCS, extensions,
ILPXX, IEEE support, CPUs with the same revision belonging to two
different architectures and vice-versa. Not to mention that we have
two back-ends, and one architecture (ARMv8 is split between the two).
And all the brand names that people mad up during the years
(StrongARM, XScale, Krait, Tegra) which map to custom features, etc.

But the way we're solving this, via out TargetParser, is to create
tables of default/allowed values, so that users will often get what
they want, even if they don't specify most of it. I imagine that MIPS
would also benefit from a TargetParser. And, if we keep the complexity
in the parser and the driver, we won't need to store much in the IR,
IFF they have the same meaning everywhere. So, whatever we spit out in
the IR has to be necessary and sufficient to get the meaning "just


More information about the llvm-dev mailing list