> -----Original Message----- > From: Renato Golin [mailto:renato.golin at linaro.org] > Sent: 08 July 2015 16:09 > 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 15:31, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > > The first reason is that compiler options can overrule the triple but leave > > it unchanged. For example, in GCC mips-linux-gnu-gcc normally produces > > 32-bit MIPS-I output using the O32 ABI, but 'mips-linux-gnu-gcc –mips64' > > normally produces 64-bit MIPS-III output using the N32 ABI. Like GCC, > > compiler options to mips-linux-gnu-clang should (and mostly do but MIPS > has > > a few crashing cases caused by triple misuse) overrule the triple. However, > > we don't mutate the triple to reflect this so any decisions based on the > > overridable state cannot rely on the triple to accurately reflect the > > desired behaviour. > > Another very annoying fact is that the Clang driver re-parses triples > many times, and sometimes they change the triple based on a CPU, and > then end up with a different CPU. > > There was a bug that if you passed "thumbv7", it would not recognise, > pick "ARM7TDMI" CPU, and later change the triple to "armv4t" because > of that, and pass *that* to the internal processes (GAS, IAS, linker). > > This bug has been fixed by adding "thumb" to it, but the underlying > reason it happened means there are plenty of other similar bugs > waiting to happen. We need to fix the mechanism in which we understand > targets, and having an unambiguous description that spans across *all* > LLVM projects (including Clang, LLD, LLDB) and tools (llc, lli, > llvm-mc, etc) is the ultimate goal. > > Most targets do not have those problems, but Mips and ARM are a big > mess. That's why we're so interested in making that happen.This reminded me of something I noticed in passing and haven't investigated yet. I think TargetRegistry::lookupTarget(const std::string &ArchName, Triple&, std::string&) can do this kind of thing when ArchName is a registered architecture but is not understood by Triple::getArchTypeForLLVMName(). I haven't had chance to try it but it looks like you'd get the intended target architecture without updating the triple to match (so x86_64-linux-gnu could target a completely different architecture).> > This configure-by-source-patch approach seems to make > > some people uncomfortable so we may have to find another way to > configure > > the triples (tablegen?). > > Another option that would make *all* distributions happy would be to > adopt the same approach as GCC and have CMake options for default ABI > choices. > > This would be harder to implement, but we can hide the mess under a > separate class (TargetABI?). I actually prefer this solution to either > tablegen or patch-sets.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. If we take this route, I'm hoping I don't need to do autoconf since I don't know it very well.> > a. Maintain backwards compatibility with IR using triples, at least > > for a while. > > Probably forever... :( > > Again, this can be isolated in TargetABI or some other place.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.
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. 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. :)> 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
> -----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, > --renatoI 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.