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

Daniel Sanders Daniel.Sanders at imgtec.com
Thu Jul 9 03:06:58 PDT 2015

-----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 x8664-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 $llvmsrc -DLLVMTARGETSTOBUILD="ARM;AArch64;X86" -DLLVMTARGETSDEFAULTS="armv7a-linux-gnueabihf;aarch64-linux- gnu;x8664-linux-gnu" Would work pretty easy in the same way TARGETSTOBUILD 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.

More information about the llvm-dev mailing list