[LLVMdev] The Trouble with Triples

[Daniel Sanders]

> -----Original Message-----
> From: Renato Golin [mailto:renato.golin at linaro.org]
> Sent: 09 July 2015 10:33
> 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 9 July 2015 at 10:25, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
> > I agree that the target architecture is the one that should be configured,
> but which architecture is that? In GCC, this is obvious because there is only
> one target triple in each build of the compiler. Similarly, in clang's there is only
> one native triple in each build so that case has an obvious answer too.
> However, for cross-compilation with clang we have all possible targets to
> choose from. How would CMake know whether to apply the customizations
> specified in the CMake variables to 'clang -target armv7-linux-gnu', 'clang -
> target mips-mti-linux-gnu', or 'clang -target x86_64-linux-android'?
> 
> That's why I said this is a "GCC thing"... :)
> 
> Apart from using a config file, adding multiple triples to the CMake
> command line would work ok-ish. The other unspecified targets would
> keep their defaults, if built.
> 
> Something like:
> 
> $ cmake $llvm_src -DLLVM_TARGETS_TO_BUILD="ARM;AArch64;X86"
> -DLLVM_TARGETS_DEFAULTS="armv7a-linux-gnueabihf;aarch64-linux-
> gnu;x86_64-linux-gnu"
> 
> Would work pretty easy in the same way TARGETS_TO_BUILD already work.

That makes sense to me with a small tweak. Different triples having different customizations is likely to be quite common for ARM and MIPS in particular so I'd suggest using lists of triple=tuple pairs. For example:
	-DLLVM_TARGETS_DEFAULTS="armv7a-linux-gnueabihf=...armv7atuple...;aarch64-linux-gnu=...aarch64tuple...;x86_64-linux-gnu=...x86_64tuple..."
 
> > Some of my colleagues from other projects have suggested the same thing
> off-list. It sounds like a good solution to me. I haven't given much thought to
> the details yet, but the one concern that springs to mind is that a simple
> config file (e.g. a triple -> tuple map) is likely to repeat itself a lot, and
> avoiding that redundancy moves the config file towards a small scripting
> language. Finding the right balance might be tricky.
> 
> Adding another DSL would be a barrier... I believe that's why you
> suggested tablegen.

That's right.

> I'm only foreseeing a couple of fields per target anyway, so a simple
> json file with overriding semantics would work. The default one in
> LLVM may be big and ugly, and distros only override what they want,
> making their patches as simple as they need to be.

That makes sense to me.