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

[Louis Gerbarg]

> On Aug 21, 2014, at 12:23 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> 
> On 20 Aug 2014, at 18:03, Jim Grosbach <grosbach at apple.com> wrote:
> 
>> There’s a few more subtleties, but that’s a reasonable analogy. While the sub-arch is related to a -march= setting, it is very definitely not the same thing. It’s not even just the sub-arch. Consider, for example, that “thumb” and “arm” have separate top-level triple values.
>> 
>> Yes, this whole system of how the arch and sub arch triple stuff works is brittle and ugly. Now that we have module level attributes and such, it’s probably possible to design something more sane. It’s debatable whether it’s worth the effort, but it’s possible.
> 
> We had a little bit of discussion recently about treating triples as config file names.  The triple would, in this model, *just* be a name and would define a file that contained a load of command-line options (-mabi, -mcpu, --sysroot, -B, and so on).  We'd ship some, people wanting to ship their own SDKs could ship other ones.
> 
> Does this make sense to anyone else?


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.

Louis