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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140819/a38a5e53/attachment.html>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140820/88bb64a1/attachment.html>

On 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?
The x86_64h triple is specifically targeted for a subclass of Haswell features.
For instance, IIRC, unlike core-avx2, it does not have the AES feature.
> 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.
This is basically a mix of x86_64, -march, and a few target features.

Cheers,
Q. 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140820/00dc26b7/attachment.html>

> 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>