Jim Grosbach
2014-Aug-20 17:03 UTC
[LLVMdev] llvm::Triple support for haswell-enabled x86_64
> On Aug 20, 2014, at 9:37 AM, Reid Kleckner <rnk at google.com> wrote: > > On Tue, Aug 19, 2014 at 10:37 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Tue, Aug 19, 2014 at 5:05 PM, Jim Grosbach <grosbach at apple.com> wrote: > Note that it’s not exactly equivalent to enabling -march=core-avx2. It’s really close, but not 100% the same. > > What is the difference? and why? It seems really confusing to have this divergence, or to be unable to replicate the *exact* behavior of this (very weird, and IMO *bad* triple) with the standard triple of 'x86_64-...' and an '-march' flag. > > It just seems like a reinvention of i386, i486, and iN86, probably for all of the same reasons. If you can encode all the important things in the triple, you can have different library directories for distributions, etc.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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140820/d6c520d6/attachment.html>
David Chisnall
2014-Aug-21 07:23 UTC
[LLVMdev] llvm::Triple support for haswell-enabled x86_64
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? David
Louis Gerbarg
2014-Aug-21 16:30 UTC
[LLVMdev] llvm::Triple support for haswell-enabled x86_64
> 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