llvm dev - Aug 2014 - [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>

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

> 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