| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
-march=native in clang.
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__ppc__.
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
|
|
|
|
|
|
|
|
|
| |
sys::getHostCPUName()."
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
|
|
|
|
|
|
| |
necessary)
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
|