The intended semantics mirror autoconf, where the user is able to
specify a host triple, but if it's left to the build system then
"config.guess" is invoked for the default.

This also renames the LLVM_HOSTTRIPLE define to LLVM_HOST_TRIPLE to
fit in with the style of the surrounding defines.

llvm-svn: 181112

llvm-svn: 181005

Testing for _XCR_XFEATURE_ENABLED_MASK instead of a specific MSVC version because some MSVC 2010 SP1 installations do not have the _xgetbv intrinsic.  Patch thanks to Serge Pavlov!

llvm-svn: 180125

llvm-svn: 179995

llvm-svn: 178674

Testing for Visual Studio 2010 SP1 or greater before calling the _xgetbv intrinsic.  This also fixes a minor code formatting issue.

llvm-svn: 178666

when getting the host processor information.  It emits a .byte sequence on GNUC compilers to work around lack of xgetbv support with older assemblers, and resolves a comment typo found in the previous patch.

llvm-svn: 178636

Rolling back the AVX support patch due to breaking a gcc 4.6 build bot that doesn't understand the xgetbv instruction for some reason.  Will revisit when time permits.

llvm-svn: 178614

llvm-svn: 178604

when getting the host processor information.

llvm-svn: 178598

llvm-svn: 176130

In r143502, we renamed getHostTriple() to getDefaultTargetTriple()
as part of work to allow the user to supply a different default
target triple at configure time.  This change also affected the JIT.
However, it is inappropriate to use the default target triple in the
JIT in most circumstances because this will not necessarily match
the current architecture used by the process, leading to illegal
instruction and other such errors at run time.

Introduce the getProcessTriple() function for use in the JIT and
its clients, and cause the JIT to use it.  On architectures with a
single bitness, the host and process triples are identical.  On other
architectures, the host triple represents the architecture of the
host CPU, while the process triple represents the architecture used
by the host CPU to interpret machine code within the current process.
For example, when executing 32-bit code on a 64-bit Linux machine,
the host triple may be 'x86_64-unknown-linux-gnu', while the process
triple may be 'i386-unknown-linux-gnu'.

This fixes JIT for the 32-on-64-bit (and vice versa) build on non-Apple
platforms.

Differential Revision: http://llvm-reviews.chandlerc.com/D254

llvm-svn: 172627

llvm-svn: 170085

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

No testcase, as this is only testable on a C-A15 board.

llvm-svn: 167108

llvm-svn: 164714

llvm-svn: 163710

Atom buildbot will auto-detect Atom.

llvm-svn: 160521

when run on an Intel Atom processor. The failures have arisen due
to changes elsewhere in the trunk over the past 8 weeks or so.

These failures were not detected by the Atom buildbot because the
CPU on the Atom buildbot was not being detected as an Atom CPU.
The fix for this problem is in Host.cpp and X86Subtarget.cpp, but
shall remain commented out until the current set of Atom test failures
are fixed.

Patch by Andy Zhang and Tyler Nowicki!

llvm-svn: 160451

The cpuid registers are only available in privileged mode so we don't have
an OS-independent way of implementing this. ARM doesn't provide a list of
processor IDs so the list is somewhat incomplete.

llvm-svn: 159228

POWER4 is a 64-bit CPU (better matched to the 970).
The g3 is really the 750 (no altivec), the g4+ is the 74xx (not the 750).

Patch by Andreas Tobler.

llvm-svn: 158363

Original commit message:
Move PPC host-CPU detection logic from PPCSubtarget into sys::getHostCPUName().

Both the new Linux functionality and the old Darwin functions have been moved.
This change also allows this information to be queried directly by clang and
other frontends (clang, for example, will now have real -mcpu=native support).

llvm-svn: 158349

This commit broke most of the PowerPC unit tests when running on
Intel/Apple.

llvm-svn: 158345

Both the new Linux functionality and the old Darwin functions have been moved.
This change also allows this information to be queried directly by clang and
other frontends (clang, for example, will now have real -mcpu=native support).

llvm-svn: 158337

For the Family 6 switch in sys::getHostCPUName, an unrecognized model was
reported as "i686".  That's a really bad default since it means that new
CPUs will be treated as if they can only use 32-bit code.  This just looks
at the cpuid extended feature flag for 64 bit support, and if that is set,
it uses a default x86-64 cpu.  Similar logic is already used for the Family
15 code.  <rdar://problem/11314502>

llvm-svn: 156486

Lincroft and Medfield.

llvm-svn: 156025

llvm-svn: 155402

llvm-svn: 148284

llvm-svn: 147846

llvm-svn: 145607

llvm-svn: 138573

llvm-svn: 134759

According to Intel Application Note 485, this value is used for
"Intel Core i7 and Intel Xeon processor".  Just include it with the other
"corei7-avx" entries.

llvm-svn: 134750

llvm-svn: 132772

llvm-svn: 131730

llvm-svn: 128920

llvm-svn: 120298

llvm-svn: 114310

llvm-svn: 114302

llvm-svn: 113486