[LLVMdev] llvm::Triple support for haswell-enabled x86_64

[Louis Gerbarg]

> On Aug 21, 2014, at 9:39 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> 
> On 21 Aug 2014, at 17:30, Louis Gerbarg <lgg at apple.com> wrote:
> 
>> I’d love a way to only compile in the triples we need instead of having everyone pull in all of the strings from  lib/Support/Triple.cpp even when we don’t include the backend, but I do not like the idea of forcing llvm to read a file. It is completely reasonable to have a sandboxed process that doesn’t have file access and can compile in and out of memory buffers via IPC. Taking a task that previously did not require access to a filesystem and adding that dependency seems wrong to me. I’m also uncomfortable with the notion of different compilers shipping with the same triple and it meaning different things, but I am not sure if you are proposing that.
>> 
>> Personally I would be a lot more comfortable with moving to a model where the backends register their triples with the compiler, that way when we compile without a backend we could avoid all of its strings, and it would move the meaning of the triples (particularly the sub targets) closer to what they impact. It would also get rid of what is essentially a thousand lines of switch statements in Triple.cpp.
> 
> The problem with this is the use case where you want to use the fact that the LLVM tools are intrinsically platform independent and ship a sysroot that contains your libraries, but don't want to have to bundle a copy of clang that is identical to the one that the user already has on their system.  Currently, you can create a symlink to {triple}-clang and you have a clang that can target that triple, but the triple is not expressive enough for all of the stuff that you care about.  At a minimum, you want:
> 
> - ABI
> - CPU
> - Sysroot location (this absolutely can not be baked in at compile time to be generally useful)
> - Path to platform-specific tools (e.g. linker)
> 
> For things that embed LLVM for a specific purpose, there's no problem in baking the mapping from triples to something sane into the code, but for generic toolchain components (cc, c++, as, objdump, readelf, size, strings, strip, and so on), being able to construct target-specific variants by just providing a config file and have that automatically consulted by a specially named symlink is likely to be a win.
> 
> We currently have to implement this by having a shell script wrapper that execs the compiler, but the cost of the shell is quite measurable in compile times.

How complicated is the shell script? If the only concern is that the shell is slow then it seems like rewriting the shell script in C would solve your problems. We actually do something similar on OS X, /usr/bin/clang is not a copy of clang or a symlink, it is an executable that redirects to the currently configured toolchain.

Louis