200 lines
6.2 KiB
Plaintext
200 lines
6.2 KiB
Plaintext
|
//===---------------------------------------------------------------------===//
|
||
|
|
|
||
|
|
Common register allocation / spilling problem:
|
||
|
|
|
||
|
|
mul lr, r4, lr
|
||
|
|
str lr, [sp, #+52]
|
||
|
|
ldr lr, [r1, #+32]
|
||
|
|
sxth r3, r3
|
||
|
|
ldr r4, [sp, #+52]
|
||
|
|
mla r4, r3, lr, r4
|
||
|
|
|
||
|
|
can be:
|
||
|
|
|
||
|
|
mul lr, r4, lr
|
||
|
|
mov r4, lr
|
||
|
|
str lr, [sp, #+52]
|
||
|
|
ldr lr, [r1, #+32]
|
||
|
|
sxth r3, r3
|
||
|
|
mla r4, r3, lr, r4
|
||
|
|
|
||
|
|
and then "merge" mul and mov:
|
||
|
|
|
||
|
|
mul r4, r4, lr
|
||
|
|
str r4, [sp, #+52]
|
||
|
|
ldr lr, [r1, #+32]
|
||
|
|
sxth r3, r3
|
||
|
|
mla r4, r3, lr, r4
|
||
|
|
|
||
|
|
It also increase the likelihood the store may become dead.
|
||
|
|
|
||
|
|
//===---------------------------------------------------------------------===//
|
||
|
|
|
||
|
|
bb27 ...
|
||
|
|
...
|
||
|
|
%reg1037 = ADDri %reg1039, 1
|
||
|
|
%reg1038 = ADDrs %reg1032, %reg1039, %noreg, 10
|
||
|
|
Successors according to CFG: 0x8b03bf0 (#5)
|
||
|
|
|
||
|
|
bb76 (0x8b03bf0, LLVM BB @0x8b032d0, ID#5):
|
||
|
|
Predecessors according to CFG: 0x8b0c5f0 (#3) 0x8b0a7c0 (#4)
|
||
|
|
%reg1039 = PHI %reg1070, mbb<bb76.outer,0x8b0c5f0>, %reg1037, mbb<bb27,0x8b0a7c0>
|
||
|
|
|
||
|
|
Note ADDri is not a two-address instruction. However, its result %reg1037 is an
|
||
|
|
operand of the PHI node in bb76 and its operand %reg1039 is the result of the
|
||
|
|
PHI node. We should treat it as a two-address code and make sure the ADDri is
|
||
|
|
scheduled after any node that reads %reg1039.
|
||
|
|
|
||
|
|
//===---------------------------------------------------------------------===//
|
||
|
|
|
||
|
|
Use local info (i.e. register scavenger) to assign it a free register to allow
|
||
|
|
reuse:
|
||
|
|
ldr r3, [sp, #+4]
|
||
|
|
add r3, r3, #3
|
||
|
|
ldr r2, [sp, #+8]
|
||
|
|
add r2, r2, #2
|
||
|
|
ldr r1, [sp, #+4] <==
|
||
|
|
add r1, r1, #1
|
||
|
|
ldr r0, [sp, #+4]
|
||
|
|
add r0, r0, #2
|
||
|
|
|
||
|
|
//===---------------------------------------------------------------------===//
|
||
|
|
|
||
|
|
LLVM aggressively lift CSE out of loop. Sometimes this can be negative side-
|
||
|
|
effects:
|
||
|
|
|
||
|
|
R1 = X + 4
|
||
|
|
R2 = X + 7
|
||
|
|
R3 = X + 15
|
||
|
|
|
||
|
|
loop:
|
||
|
|
load [i + R1]
|
||
|
|
...
|
||
|
|
load [i + R2]
|
||
|
|
...
|
||
|
|
load [i + R3]
|
||
|
|
|
||
|
|
Suppose there is high register pressure, R1, R2, R3, can be spilled. We need
|
||
|
|
to implement proper re-materialization to handle this:
|
||
|
|
|
||
|
|
R1 = X + 4
|
||
|
|
R2 = X + 7
|
||
|
|
R3 = X + 15
|
||
|
|
|
||
|
|
loop:
|
||
|
|
R1 = X + 4 @ re-materialized
|
||
|
|
load [i + R1]
|
||
|
|
...
|
||
|
|
R2 = X + 7 @ re-materialized
|
||
|
|
load [i + R2]
|
||
|
|
...
|
||
|
|
R3 = X + 15 @ re-materialized
|
||
|
|
load [i + R3]
|
||
|
|
|
||
|
|
Furthermore, with re-association, we can enable sharing:
|
||
|
|
|
||
|
|
R1 = X + 4
|
||
|
|
R2 = X + 7
|
||
|
|
R3 = X + 15
|
||
|
|
|
||
|
|
loop:
|
||
|
|
T = i + X
|
||
|
|
load [T + 4]
|
||
|
|
...
|
||
|
|
load [T + 7]
|
||
|
|
...
|
||
|
|
load [T + 15]
|
||
|
|
//===---------------------------------------------------------------------===//
|
||
|
|
|
||
|
|
It's not always a good idea to choose rematerialization over spilling. If all
|
||
|
|
the load / store instructions would be folded then spilling is cheaper because
|
||
|
|
it won't require new live intervals / registers. See 2003-05-31-LongShifts for
|
||
|
|
an example.
|
||
|
|
|
||
|
|
//===---------------------------------------------------------------------===//
|
||
|
|
|
||
|
|
With a copying garbage collector, derived pointers must not be retained across
|
||
|
|
collector safe points; the collector could move the objects and invalidate the
|
||
|
|
derived pointer. This is bad enough in the first place, but safe points can
|
||
|
|
crop up unpredictably. Consider:
|
||
|
|
|
||
|
|
%array = load { i32, [0 x %obj] }** %array_addr
|
||
|
|
%nth_el = getelementptr { i32, [0 x %obj] }* %array, i32 0, i32 %n
|
||
|
|
%old = load %obj** %nth_el
|
||
|
|
%z = div i64 %x, %y
|
||
|
|
store %obj* %new, %obj** %nth_el
|
||
|
|
|
||
|
|
If the i64 division is lowered to a libcall, then a safe point will (must)
|
||
|
|
appear for the call site. If a collection occurs, %array and %nth_el no longer
|
||
|
|
point into the correct object.
|
||
|
|
|
||
|
|
The fix for this is to copy address calculations so that dependent pointers
|
||
|
|
are never live across safe point boundaries. But the loads cannot be copied
|
||
|
|
like this if there was an intervening store, so may be hard to get right.
|
||
|
|
|
||
|
|
Only a concurrent mutator can trigger a collection at the libcall safe point.
|
||
|
|
So single-threaded programs do not have this requirement, even with a copying
|
||
|
|
collector. Still, LLVM optimizations would probably undo a front-end's careful
|
||
|
|
work.
|
||
|
|
|
||
|
|
//===---------------------------------------------------------------------===//
|
||
|
|
|
||
|
|
The ocaml frametable structure supports liveness information. It would be good
|
||
|
|
to support it.
|
||
|
|
|
||
|
|
//===---------------------------------------------------------------------===//
|
||
|
|
|
||
|
|
The FIXME in ComputeCommonTailLength in BranchFolding.cpp needs to be
|
||
|
|
revisited. The check is there to work around a misuse of directives in inline
|
||
|
|
assembly.
|
||
|
|
|
||
|
|
//===---------------------------------------------------------------------===//
|
||
|
|
|
||
|
|
It would be good to detect collector/target compatibility instead of silently
|
||
|
|
doing the wrong thing.
|
||
|
|
|
||
|
|
//===---------------------------------------------------------------------===//
|
||
|
|
|
||
|
|
It would be really nice to be able to write patterns in .td files for copies,
|
||
|
|
which would eliminate a bunch of explicit predicates on them (e.g. no side
|
||
|
|
effects). Once this is in place, it would be even better to have tblgen
|
||
|
|
synthesize the various copy insertion/inspection methods in TargetInstrInfo.
|
||
|
|
|
||
|
|
//===---------------------------------------------------------------------===//
|
||
|
|
|
||
|
|
Stack coloring improvements:
|
||
|
|
|
||
|
|
1. Do proper LiveStacks analysis on all stack objects including those which are
|
||
|
|
not spill slots.
|
||
|
|
2. Reorder objects to fill in gaps between objects.
|
||
|
|
e.g. 4, 1, <gap>, 4, 1, 1, 1, <gap>, 4 => 4, 1, 1, 1, 1, 4, 4
|
||
|
|
|
||
|
|
//===---------------------------------------------------------------------===//
|
||
|
|
|
||
|
|
The scheduler should be able to sort nearby instructions by their address. For
|
||
|
|
example, in an expanded memset sequence it's not uncommon to see code like this:
|
||
|
|
|
||
|
|
movl $0, 4(%rdi)
|
||
|
|
movl $0, 8(%rdi)
|
||
|
|
movl $0, 12(%rdi)
|
||
|
|
movl $0, 0(%rdi)
|
||
|
|
|
||
|
|
Each of the stores is independent, and the scheduler is currently making an
|
||
|
|
arbitrary decision about the order.
|
||
|
|
|
||
|
|
//===---------------------------------------------------------------------===//
|
||
|
|
|
||
|
|
Another opportunitiy in this code is that the $0 could be moved to a register:
|
||
|
|
|
||
|
|
movl $0, 4(%rdi)
|
||
|
|
movl $0, 8(%rdi)
|
||
|
|
movl $0, 12(%rdi)
|
||
|
|
movl $0, 0(%rdi)
|
||
|
|
|
||
|
|
This would save substantial code size, especially for longer sequences like
|
||
|
|
this. It would be easy to have a rule telling isel to avoid matching MOV32mi
|
||
|
|
if the immediate has more than some fixed number of uses. It's more involved
|
||
|
|
to teach the register allocator how to do late folding to recover from
|
||
|
|
excessive register pressure.
|
||
|
|
|