| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done by pushing physical register definitions close to their
use, which happens to handle flag definitions if they're not glued to
the branch. This seems to be generally a good thing though, so I
didn't need to add a target hook yet.
The primary motivation is to generate code closer to what people
expect and rule out missed opportunity from enabling macro-op
fusion. As a side benefit, we get several 2-5% gains on x86
benchmarks. There is one regression:
SingleSource/Benchmarks/Shootout/lists slows down be -10%. But this is
an independent scheduler bug that will be tracked separately.
See rdar://problem/9283108.
Incidentally, pre-RA scheduling is only half the solution. Fixing the
later passes is tracked by:
<rdar://problem/8932804> [pre-RA-sched] on x86, attempt to schedule CMP/TEST adjacent with condition jump
Fixes:
<rdar://problem/9262453> Scheduler unnecessary break of cmp/jump fusion
llvm-svn: 129508
|
|
|
|
|
|
| |
improvements, that will lead to fixing PR6627.
llvm-svn: 129504
|
|
|
|
| |
llvm-svn: 129503
|
|
|
|
|
|
|
|
|
|
|
|
| |
instruction around, reducing work.
Greatly simplify handling of debug instructions. There is no need to
build up a vector of them and then move them into the one predecessor
if we're processing a block. Instead just rescan the block and *copy*
them into the pred. If a block gets merged into multiple preds, this
will retain more debug info.
llvm-svn: 129502
|
|
|
|
| |
llvm-svn: 129501
|
|
|
|
|
|
| |
(movzx/movsx) because they give more information. Revert that part of the patch.
llvm-svn: 129498
|
|
|
|
|
|
| |
cases, it's much nicer and more informative reading the alias.
llvm-svn: 129497
|
|
|
|
|
|
| |
the alias".
llvm-svn: 129485
|
|
|
|
|
|
| |
where the RHS is of the legal type for the new operation.
llvm-svn: 129484
|
|
|
|
|
|
| |
rdar://problem/9280370
llvm-svn: 129480
|
|
|
|
|
|
|
|
| |
the same allocation size but different primitive sizes(e.g., <3xi32> and
<4xi32>). When ScalarRepl promotes them, it can't use a bit cast but
should use a shuffle vector instead.
llvm-svn: 129472
|
|
|
|
|
|
|
|
| |
instructions (tBcc and t2Bcc).
rdar://problem/9280470
llvm-svn: 129471
|
|
|
|
|
|
| |
rdar://problem/9279440
llvm-svn: 129469
|
|
|
|
| |
llvm-svn: 129468
|
|
|
|
|
|
|
| |
ignored. There was a test to catch this, but it was just blindly updated in
a large change. This fixes another part of <rdar://problem/9275290>.
llvm-svn: 129466
|
|
|
|
| |
llvm-svn: 129463
|
|
|
|
|
|
|
|
| |
as such.
rdar://problem/9276651
llvm-svn: 129462
|
|
|
|
|
|
| |
understand actual reason behind this fixme. Spot checking suggest that newer gdb does not need this.
llvm-svn: 129461
|
|
|
|
|
|
|
|
| |
not properly handled.
rdar://problem/9276427
llvm-svn: 129456
|
|
|
|
|
|
| |
http://llvm.org/viewvc/llvm-project?view=rev&revision=129387.
llvm-svn: 129451
|
|
|
|
| |
llvm-svn: 129450
|
|
|
|
|
|
|
|
|
| |
LoopUnroll class's ctor. Doing so
will allow multiple context with different loop unroll parameters to run. This is a minor change and no effect
on existing application.
llvm-svn: 129449
|
|
|
|
| |
llvm-svn: 129447
|
|
|
|
| |
llvm-svn: 129445
|
|
|
|
|
|
| |
related tweaks to ExprMapKeyType.
llvm-svn: 129443
|
|
|
|
| |
llvm-svn: 129442
|
|
|
|
| |
llvm-svn: 129441
|
|
|
|
| |
llvm-svn: 129439
|
|
|
|
| |
llvm-svn: 129435
|
|
|
|
|
|
|
| |
the max itself, so it is not easy to write a test case for this, but I added a
test case that would fail if the code in AsmPrinter were removed.
llvm-svn: 129432
|
|
|
|
| |
llvm-svn: 129429
|
|
|
|
|
|
|
| |
alignment for its type, use the minimum of the specified alignment and the ABI
alignment. This fixes <rdar://problem/9275290>.
llvm-svn: 129428
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
latency.
Additional fixes:
Do something reasonable for subtargets with generic
itineraries by handle node latency the same as for an empty
itinerary. Now nodes default to unit latency unless an itinerary
explicitly specifies a zero cycle stage or it is a TokenFactor chain.
Original fixes:
UnitsSharePred was a source of randomness in the scheduler: node
priority depended on the queue data structure. I rewrote the recent
VRegCycle heuristics to completely replace the old heuristic without
any randomness. To make the ndoe latency adjustments work, I also
needed to do something a little more reasonable with TokenFactor. I
gave it zero latency to its consumers and always schedule it as low as
possible.
llvm-svn: 129421
|
|
|
|
| |
llvm-svn: 129419
|
|
|
|
| |
llvm-svn: 129417
|
|
|
|
|
|
| |
Implement the ones that were missing in the asm streamer.
llvm-svn: 129413
|
|
|
|
|
|
| |
rdar://problem/9273947
llvm-svn: 129411
|
|
|
|
|
|
|
|
|
|
| |
instructions.
The ARMARM specifies these instructions as unpredictable when storing the
writeback register. This shouldn't affect code generation much since storing a
pointer to itself is quite rare.
llvm-svn: 129409
|
|
|
|
|
|
|
|
| |
registers for fast allocation.
Fixes rdar://9207598
llvm-svn: 129408
|
|
|
|
| |
llvm-svn: 129407
|
|
|
|
| |
llvm-svn: 129406
|
|
|
|
| |
llvm-svn: 129405
|
|
|
|
| |
llvm-svn: 129403
|
|
|
|
|
|
| |
In case of multiple compile unit in one object file, each compile unit is responsible for its own set of type entries anyway. This refactoring makes this obvious.
llvm-svn: 129402
|
|
|
|
|
|
|
|
|
| |
Now that we have a first-class way to represent unaligned loads, the unaligned
load intrinsics are superfluous.
First part of <rdar://problem/8460511>.
llvm-svn: 129401
|
|
|
|
| |
llvm-svn: 129400
|
|
|
|
|
|
|
|
|
|
| |
In addition, the base register is not rGPR, but GPR with th exception that:
if n == 15 then UNPREDICTABLE
rdar://problem/9273836
llvm-svn: 129391
|
|
|
|
|
|
|
| |
Use a Bitvector instead, we didn't need the smaller memory footprint anyway.
This makes the greedy register allocator 10% faster.
llvm-svn: 129390
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add handling for tracking the relocations on symbols and resolving them.
Keep track of the relocations even after they are resolved so that if
the RuntimeDyld client moves the object, it can update the address and any
relocations to that object will be updated.
For our trival object file load/run test harness (llvm-rtdyld), this enables
relocations between functions located in the same object module. It should
be trivially extendable to load multiple objects with mutual references.
As a simple example, the following now works (running on x86_64 Darwin 10.6):
$ cat t.c
int bar() {
return 65;
}
int main() {
return bar();
}
$ clang t.c -fno-asynchronous-unwind-tables -o t.o -c
$ otool -vt t.o
t.o:
(__TEXT,__text) section
_bar:
0000000000000000 pushq %rbp
0000000000000001 movq %rsp,%rbp
0000000000000004 movl $0x00000041,%eax
0000000000000009 popq %rbp
000000000000000a ret
000000000000000b nopl 0x00(%rax,%rax)
_main:
0000000000000010 pushq %rbp
0000000000000011 movq %rsp,%rbp
0000000000000014 subq $0x10,%rsp
0000000000000018 movl $0x00000000,0xfc(%rbp)
000000000000001f callq 0x00000024
0000000000000024 addq $0x10,%rsp
0000000000000028 popq %rbp
0000000000000029 ret
$ llvm-rtdyld t.o -debug-only=dyld ; echo $?
Function sym: '_bar' @ 0
Function sym: '_main' @ 16
Extracting function: _bar from [0, 15]
allocated to 0x100153000
Extracting function: _main from [16, 41]
allocated to 0x100154000
Relocation at '_main' + 16 from '_bar(Word1: 0x2d000000)
Resolving relocation at '_main' + 16 (0x100154010) from '_bar (0x100153000)(pcrel, type: 2, Size: 4).
loaded '_main' at: 0x100154000
65
$
llvm-svn: 129388
|
|
|
|
|
|
| |
rdar://problem/9269047
llvm-svn: 129387
|