[LLVMdev] The Trouble with Triples

[Renato Golin]

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.


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

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.


> I don't think this IR change is the same as changing build systems. My thinking is that llvm::Module has a TargetTuple and AssemblyWriter/BitcodeWriter will always write out this tuple. With this, natural recompilation should remove the 'target triple' statements from all IR in the wild in a reasonable timescale.

Oh, I thought you were referring to change how triples were
interpreted by the driver, which unfortunately, has to be done the GCC
way for all legacy ones. :(

In the module, I agree, it should be ok to deprecate that fast.

cheers,
--renato