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

Sounds good, I'll give it a try sooner or later.  I've never messed with
triples, so is there anything I need to be aware of so I don't break any
code on other platforms?  In particular, I want
llvm::sys::getDefaultTargetTriple() to return me this new haswell-aware
triple, so what do I need to do to ensure that I don't break anyone else
who is running one of these systems and previously had a different default
triple?


On Tue, Aug 19, 2014 at 4:53 PM, Jim Grosbach <grosbach at apple.com>
wrote:
> Sure, go for it. It’d be a fairly natural fit for a SubArchType.
>
>
>
> > On Aug 19, 2014, at 2:44 PM, Zachary Turner <zturner at
google.com> wrote:
> >
> > I'm working on LLDB and we have a bunch of code that is manually
> manipulating triples and doing a bunch of nasty stuff to account for the
> fact that llvm::Triple doesn't currently have a way to detect x86_64h.
> >
> > Is this something that llvm::Triple could be modified to support?
> Either as a new ArchType, or a new SubArchType?
> > _______________________________________________
> > 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/20140819/dfc882bd/attachment.html>

That triple is currently only used on Darwin. Its exact meaning there can be
seen in the clang driver where the subtarget features are passed to the target.
Note that it’s not exactly equivalent to enabling -march=core-avx2. It’s really
close, but not 100% the same. My main suggestion there is to make its meaning on
other platforms be the same. Having the same triple mean slightly different
things depending on platform would get really ugly really fast.

In theory, the tests in tree should help make sure things don’t break for
Darwin. In practice, that’s true for the basics, but probably optimistic for
subtleties. If you include myself and Quentin Colombet on phab (or cc us on the
lists) for patches in the area, we can have a look and help anticipate issues.

-Jim
> On Aug 19, 2014, at 4:57 PM, Zachary Turner <zturner at google.com>
wrote:
> 
> Sounds good, I'll give it a try sooner or later.  I've never messed
with triples, so is there anything I need to be aware of so I don't break
any code on other platforms?  In particular, I want
llvm::sys::getDefaultTargetTriple() to return me this new haswell-aware triple,
so what do I need to do to ensure that I don't break anyone else who is
running one of these systems and previously had a different default triple?
> 
> 
> On Tue, Aug 19, 2014 at 4:53 PM, Jim Grosbach <grosbach at apple.com>
wrote:
> Sure, go for it. It’d be a fairly natural fit for a SubArchType.
> 
> 
> 
> > On Aug 19, 2014, at 2:44 PM, Zachary Turner <zturner at
google.com> wrote:
> >
> > I'm working on LLDB and we have a bunch of code that is manually
manipulating triples and doing a bunch of nasty stuff to account for the fact
that llvm::Triple doesn't currently have a way to detect x86_64h.
> >
> > Is this something that llvm::Triple could be modified to support? 
Either as a new ArchType, or a new SubArchType?
> > _______________________________________________
> > 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/20140819/f1c5a4cc/attachment.html>

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>