> -----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.
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
On 9 Jul 2015, at 10:25, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:> >> 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.The use-case that I’d really like to go from mostly-working to actually-working is the ability to create symlinked versions of clang with a triple prefix and have it behave sensibly. We can symlink clang to mips64-unknown-freebsd-clang and get a working cross-compiler, more or less, except that we also want to specify things like the default sysroot. Having the bit in the name of the compiler just be a name for a config file containing a set of command-line options would be very nice - we’d have a set of predefined names, and then if someone wanted to provide a androidsdk-v47-arm.conf (or whatever) and just drop it into a known location then they’d be able to use androidsdk-v47-arm-clang as a cross compiler. David
On 9 July 2015 at 10:39, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:> The use-case that I’d really like to go from mostly-working to actually-working is the ability to create symlinked versions of clang with a triple prefix and have it behave sensibly. We can symlink clang to mips64-unknown-freebsd-clang and get a working cross-compiler, more or less, except that we also want to specify things like the default sysroot. Having the bit in the name of the compiler just be a name for a config file containing a set of command-line options would be very nice - we’d have a set of predefined names, and then if someone wanted to provide a androidsdk-v47-arm.conf (or whatever) and just drop it into a known location then they’d be able to use androidsdk-v47-arm-clang as a cross compiler.This already works well with Clang, but is restricted to the triples that actually make sense. If you need to change anything that the triple can't, you're on your own. But I agree this is a sensible alternative, or even in conjunction, with CMake options or config files. cheers, --renato
> -----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.
On 07/09/2015 04:39 AM, David Chisnall wrote:> On 9 Jul 2015, at 10:25, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: >>> 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. > The use-case that I’d really like to go from mostly-working to actually-working is the ability to create symlinked versions of clang with a triple prefix and have it behave sensibly. We can symlink clang to mips64-unknown-freebsd-clang and get a working cross-compiler, more or less, except that we also want to specify things like the default sysroot. Having the bit in the name of the compiler just be a name for a config file containing a set of command-line options would be very nice - we’d have a set of predefined names, and then if someone wanted to provide a androidsdk-v47-arm.conf (or whatever) and just drop it into a known location then they’d be able to use androidsdk-v47-arm-clang as a cross compiler. > > David >My slightly modified version of clang, ecc (http:ellcc.org) has been using config files for quite a while. I've mentioned them on the mailing list before. In the current implementation, if either the program name (via a symlink) or the argument to the -target option matches the name of a config file, that file is read and used to control the driver. I used the pre-existing YAML parser to parse the config files. A typical config file looks like this: based_on: microblaze-ellcc-linux compiler: options: - -target microblaze-ellcc-linux - -D__ELK__=1 c_include_dirs: - '$R/include/elk/microblaze' - '$R/include/elk' - '$R/include/microblaze' - '$R/include' linker: options: - -Telk.ld - -m elf32mb_linux static_crt1: $R/lib/microblaze-elk-eng/crt1.o dynamic_crt1: $R/lib/microblaze-elk-eng/Scrt1.o crtbegin: $R/lib/microblaze-linux-eng/crtbegin.o crtend: $R/lib/microblaze-linux-eng/crtend.o library_paths: - -L$R/lib/microblaze-elk-eng - -L$R/lib/elk - -L$R/lib/microblaze-linux-eng c_libraries: - -lelk - '-(' - -lc - -lcompiler-rt - '-)' The "based_on" field allows a configuration file to be based on another config file. Base config files can be compiled into the driver like "microblaze-ellcc-linux" in this example. Other examples of config files can be found at http://ellcc.org/viewvc/svn/ellcc/trunk/libecc/config/ -Rich