| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
whether sse is available. Just use consult subtarget.
No functionality changes.
llvm-svn: 80880
|
|
|
|
|
|
|
| |
conditional moves as a subtarget feature. This is the easy part of
PR4841.
llvm-svn: 80763
|
|
|
|
|
|
|
|
| |
Some other minor win64 fixes as well.
Patch by Michael Beck!
llvm-svn: 80370
|
|
|
|
|
|
|
| |
instead of X86 Subtarget. This elimianates dependencies on
X86Subtarget from X86TAI.
llvm-svn: 78746
|
|
|
|
| |
llvm-svn: 78219
|
|
|
|
|
|
| |
- Tidy up some headers.
llvm-svn: 77929
|
|
|
|
|
|
|
|
|
|
| |
Module*.
Also, dropped uses of TargetMachine where unnecessary. The only target which
still takes a TargetMachine& is Mips, I would appreciate it if someone would
normalize this to match other targets.
llvm-svn: 77918
|
|
|
|
| |
llvm-svn: 76356
|
|
|
|
|
|
| |
compilation mode) do not require extra load from stub. This fixes ExecutionEngine/2005-12-02-TailCallBug.ll.
llvm-svn: 76121
|
|
|
|
| |
llvm-svn: 75277
|
|
|
|
| |
llvm-svn: 75276
|
|
|
|
| |
llvm-svn: 75275
|
|
|
|
| |
llvm-svn: 75274
|
|
|
|
|
|
| |
"stub style pic in dynamic-no-pic" mode.
llvm-svn: 75273
|
|
|
|
|
|
| |
elimiantes the last use of GVRequiresExtraLoad, so delete it.
llvm-svn: 75244
|
|
|
|
|
|
| |
need for other purposes.
llvm-svn: 75243
|
|
|
|
|
|
|
| |
is just a trivial wrapper around "ClassifyGlobalReference", which
stole a ton of logic from LowerGlobalAddress.
llvm-svn: 75237
|
|
|
|
| |
llvm-svn: 75232
|
|
|
|
|
|
| |
more complex and slow than just directly testing what we care about.
llvm-svn: 75231
|
|
|
|
|
|
|
| |
split its handling out to PCRelGVRequiresExtraLoad, and simplify code
based on this.
llvm-svn: 75230
|
|
|
|
| |
llvm-svn: 75229
|
|
|
|
|
|
| |
in pic or dynamic-no-pic mode. Also, x86-64 never used picstylegot.
llvm-svn: 75101
|
|
|
|
|
|
| |
with DLLImport symbols even when in -static mode.
llvm-svn: 75093
|
|
|
|
|
|
| |
initialization problems.
llvm-svn: 74350
|
|
|
|
|
|
|
|
|
| |
ABI. The missing piece is support for putting "homogeneous aggregates"
into registers.
Patch by Sandeep Patel!
llvm-svn: 73095
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- added processors k8-sse3, opteron-sse3, athlon64-sse3, amdfam10, and
barcelona with appropriate sse3/4a levels
- added FeatureSSE4A for amdfam10 processors
in X86Subtarget:
- added hasSSE4A
- updated AutoDetectSubtargetFeatures to detect SSE4A
- updated GetCurrentX86CPU to detect family 15 with sse3 as k8-sse3 and
family 10h as amdfam10
New processor names match those used by gcc.
Patch by Paul Redmond!
llvm-svn: 72434
|
|
|
|
|
|
| |
relocation mode.
llvm-svn: 72160
|
|
|
|
|
|
| |
Nicolas Capens!
llvm-svn: 70057
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
llvm-svn: 66339
|
|
|
|
| |
llvm-svn: 65662
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is given, override the subtarget settings and enable 64-bit support.
This restores the earlier behavior, and fixes regressions on
Non-64-bit-capable x86-32 hosts.
This isn't necessarily the best approach, but the most obvious
alternative is to require -mcpu=x86-64 or -mattr=+64bit to be used
with -march=x86-64 when the host doesn't have 64-bit support. This
makes things little more consistent, but it's less convenient, and
it has the practical drawback of requiring lots of test changes, so
I opted for the above approach for now.
llvm-svn: 63642
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SSE2, however it's possible to disable SSE2, and the subtarget support
code thinks that if 64-bit implies SSE2 and SSE2 is disabled then
64-bit should also be disabled. Instead, just mark all the 64-bit
subtargets as explicitly supporting SSE2.
Also, move the code that makes -march=x86-64 enable 64-bit support by
default to only apply when there is no explicit subtarget. If you
need to specify a subtarget and you want 64-bit code, you'll need to
select a subtarget that supports 64-bit code.
llvm-svn: 63575
|
|
|
|
|
|
| |
Add an assert to check HasX86_64 status.
llvm-svn: 63552
|
|
|
|
| |
llvm-svn: 63542
|
|
|
|
|
|
| |
var-args, and don't allow FP return values
llvm-svn: 63495
|
|
|
|
| |
llvm-svn: 62973
|
|
|
|
|
|
| |
for example in the case of va-args. XFAIL associated tests.
llvm-svn: 62972
|
|
|
|
|
|
| |
of PR3402.
llvm-svn: 62967
|
|
|
|
| |
llvm-svn: 62279
|
|
|
|
| |
llvm-svn: 61686
|
|
|
|
| |
llvm-svn: 61603
|
|
|
|
| |
llvm-svn: 61602
|
|
|
|
|
|
| |
processors. These are significantly slower than a load followed by a bt of a register.
llvm-svn: 61557
|
|
|
|
| |
llvm-svn: 61556
|
|
|
|
|
|
|
| |
especially in the case of addresses computed from loop induction
variables.
llvm-svn: 61075
|
|
|
|
| |
llvm-svn: 60711
|
|
|
|
| |
llvm-svn: 60705
|
|
|
|
| |
llvm-svn: 60689
|
|
|
|
|
|
|
|
|
|
|
| |
loops when they can be subsumed into addressing modes.
Change X86 addressing mode check to realize that
some PIC references need an extra register.
(I believe this is correct for Linux, if not, I'm sure
someone will tell me.)
llvm-svn: 60608
|
|
|
|
|
|
| |
are a bit more complicate than I expected. Both declarations and weak definitions still need a stub indirection. However, the stubs are in data section and they contain the addresses of the actual symbols.
llvm-svn: 60571
|