| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
instruction. X86, PowerPC and ARM are implemented
llvm-svn: 49809
|
| |
|
|
| |
llvm-svn: 49808
|
| |
|
|
|
|
|
|
|
|
| |
Rename SDOperandImpl back to SDOperand.
Introduce the SDUse class that represents a use of the SDNode referred by
an SDOperand. Now it is more similar to Use/Value classes.
Patch is approved by Dan Gohman.
llvm-svn: 49795
|
| |
|
|
|
|
| |
puts its result in a 32-bit GPR.
llvm-svn: 49762
|
| |
|
|
|
|
|
|
| |
memcpy lowering code; this ensures that the size node has the desired
result type. This fixes a regression from r49572 with @llvm.memcpy.i64
on x86-32.
llvm-svn: 49761
|
| |
|
|
| |
llvm-svn: 49759
|
| |
|
|
|
|
| |
to 64-bit GPR registers on x86-64.
llvm-svn: 49757
|
| |
|
|
| |
llvm-svn: 49715
|
| |
|
|
| |
llvm-svn: 49681
|
| |
|
|
|
|
| |
memory intrinsic expansion code.
llvm-svn: 49666
|
| |
|
|
|
|
|
| |
stack tracebacks on Darwin x86-64 won't work by default;
nevertheless, everybody but me thinks this is a good idea.
llvm-svn: 49663
|
| |
|
|
|
|
| |
parts. Fixes PR1643
llvm-svn: 49611
|
| |
|
|
| |
llvm-svn: 49593
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
optimized x86-64 (and x86) calls so that they work (... at least for
my test cases).
Should fix the following problems:
Problem 1: When i introduced the optimized handling of arguments for
tail called functions (using a sequence of copyto/copyfrom virtual
registers instead of always lowering to top of the stack) i did not
handle byval arguments correctly e.g they did not work at all :).
Problem 2: On x86-64 after the arguments of the tail called function
are moved to their registers (which include ESI/RSI etc), tail call
optimization performs byval lowering which causes xSI,xDI, xCX
registers to be overwritten. This is handled in this patch by moving
the arguments to virtual registers first and after the byval lowering
the arguments are moved from those virtual registers back to
RSI/RDI/RCX.
llvm-svn: 49584
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on any current target and aren't optimized in DAGCombiner. Instead
of using intermediate nodes, expand the operations, choosing between
simple loads/stores, target-specific code, and library calls,
immediately.
Previously, the code to emit optimized code for these operations
was only used at initial SelectionDAG construction time; now it is
used at all times. This fixes some cases where rep;movs was being
used for small copies where simple loads/stores would be better.
This also cleans up code that checks for alignments less than 4;
let the targets make that decision instead of doing it in
target-independent code. This allows x86 to use rep;movs in
low-alignment cases.
Also, this fixes a bug that resulted in the use of rep;stos for
memsets of 0 with non-constant memory size when the alignment was
at least 4. It's better to use the library in this case, which
can be significantly faster when the size is large.
This also preserves more SourceValue information when memory
intrinsics are lowered into simple loads/stores.
llvm-svn: 49572
|
| |
|
|
|
|
| |
8-byte-aligned data.
llvm-svn: 49571
|
| |
|
|
| |
llvm-svn: 49569
|
| |
|
|
| |
llvm-svn: 49466
|
| |
|
|
| |
llvm-svn: 49465
|
| |
|
|
|
|
|
|
| |
MOVZQI2PQIrr. This would be better handled as a dag combine
(with the goal of eliminating the bitconvert) but I don't know
how to do that safely. Thoughts welcome.
llvm-svn: 49463
|
| |
|
|
| |
llvm-svn: 49446
|
| |
|
|
|
|
|
| |
is needed for the x86-64-ABI handling of structs that contain floating-point
members that are returned by value.
llvm-svn: 49441
|
| |
|
|
| |
llvm-svn: 49440
|
| |
|
|
| |
llvm-svn: 49389
|
| |
|
|
|
|
| |
correctly when unwind info is being generated.
llvm-svn: 49366
|
| |
|
|
|
|
| |
Corresponds to -fno-unwind-tables (usually default in gcc).
llvm-svn: 49361
|
| |
|
|
|
|
|
| |
review feedback from Chris quite a while ago. No functionality
change.
llvm-svn: 49348
|
| |
|
|
|
|
| |
by Dan Gohman is fixed.
llvm-svn: 49330
|
| |
|
|
|
|
|
|
| |
Specifically, introduction of XXX::Create methods
for Users that have a potentially variable number of
Uses.
llvm-svn: 49277
|
| |
|
|
|
|
| |
faster than shufps.
llvm-svn: 49244
|
| |
|
|
| |
llvm-svn: 49218
|
| |
|
|
| |
llvm-svn: 49158
|
| |
|
|
|
|
| |
example, extractps in 64bit mode: 66 REX 0F 3A 17, not 66 0F 3A REX 17.
llvm-svn: 49157
|
| |
|
|
| |
llvm-svn: 49156
|
| |
|
|
| |
llvm-svn: 49129
|
| |
|
|
| |
llvm-svn: 49124
|
| |
|
|
|
|
| |
it causes compile errors.
llvm-svn: 49122
|
| |
|
|
|
|
|
| |
now that llvm-gcc is lowering appropriately-sized struct returns
to i128 on x86-64.
llvm-svn: 49109
|
| |
|
|
| |
llvm-svn: 49096
|
| |
|
|
|
|
|
| |
when some another register is used for argument passing.
Currently is used on Win64.
llvm-svn: 49079
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
review feedback.
-enable-eh is still accepted but doesn't do anything.
EH intrinsics use Dwarf EH if the target supports that,
and are handled by LowerInvoke otherwise.
The separation of the EH table and frame move data is,
I think, logically figured out, but either one still
causes full EH info to be generated (not sure how to
split the metadata correctly).
MachineModuleInfo::needsFrameInfo is no longer used and
is removed.
llvm-svn: 49064
|
| |
|
|
|
|
| |
spiller doesn't do a good job of estimating the impact. Disable for now.
llvm-svn: 49059
|
| |
|
|
|
|
| |
load from gv stub.
llvm-svn: 49054
|
| |
|
|
| |
llvm-svn: 49050
|
| |
|
|
| |
llvm-svn: 49048
|
| |
|
|
| |
llvm-svn: 49046
|
| |
|
|
|
|
| |
bootstrap miscompare.
llvm-svn: 49037
|
| |
|
|
| |
llvm-svn: 49012
|
| |
|
|
| |
llvm-svn: 49011
|
| |
|
|
|
|
|
|
|
|
|
| |
not marked nounwind, or for all functions when -enable-eh
is set, provided the target supports Dwarf EH.
llvm-gcc generates nounwind in the right places; other FEs
will need to do so also. Given such a FE, -enable-eh should
no longer be needed.
llvm-svn: 49006
|