[LLVMdev] The Trouble with Triples

[Daniel Sanders]

> -----Original Message-----
> From: Renato Golin [mailto:renato.golin at linaro.org]
> Sent: 08 July 2015 19:01
> 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 8 July 2015 at 17:43, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
> > I can see a way to make the CMake option approach work nicely for native.
> The constructor can check for the default triple and apply the effects of the
> CMake options to it. I don't think there's a good way to support the multiple
> triples or heterogenous use cases via CMake options but support for that
> was more a happy coincidence rather than intentional design.
> 
> Well, I'd say the CMake options would change the behaviour for the
> target architecture, not the host, which is a GCC thing, not an LLVM
> thing.

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'?
 
> Some people have suggested config files. So we'd have (say)
> Targets.cfg on LLVM's source tree copied to the build tree, unless you
> specify -DTARGETS_CONFIG=/foo/bar/UbuntuTargets.cfg, and that would
> populate the defaults in TargetABI. Of course, this would be a big
> change and it's probably for after we do all we already planned to. :)

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.

> > As far as I know there is no backwards compatibility promise, but equally it
> doesn't seem reasonable to give no notice before removing it. I'm therefore
> thinking that we can deprecate it in one release (3.7 or 3.8), then remove it in
> the next.
> 
> Well, the problem here is that changing build systems is even harder
> than changing user code. So changes in how triples or legacy/GNU
> command line options are interpreted end up being kept *a lot* longer
> than other LLVM specific features.
> 
> cheers,
> --renato

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.