Hi folks!
I've moved on from register allocation (see Understanding IRA thread)
and onto scheduling.
In particular, I am investigating the effectiveness of the sched1
pass on our architecture and the associated interblock-scheduling
optimisation.
Let's start with sched1 ...
For our architecture at least, it seems like Richard Earnshaw is
right that sched1 is generally bad when you are using -Os, because
it can increase register pressure and cause extra spill/fill code when
you move independent instructions in between dependent instructions.
For example:
LOAD c2,c1[0]
LOAD c3,c1[1]
ADD c2,c2,c3 # depends on LOAD above it (might stall)
LOAD c3,c1[2]
ADD c2,c2,c3 # depends on LOAD above it (might stall)
LOAD c3,c1[3]
ADD c2,c2,c3 # depends on LOAD above it (might stall)
LOAD c3,c1[4]
ADD c2,c2,c3 # depends on LOAD above it (might stall)
might become:
LOAD c2,c1[0]
LOAD c3,c1[1]
LOAD c4,c1[2] # independent of first two LOADS
LOAD c5,c1[3] # independent of first two LOADS
ADD c2,c2,c3 # not dependent on preceding two insns (avoids stall)
LOAD c3,c1[4]
ADD c2,c2,c4 # not dependent on preceding three insns (avoids stall)
...
This is a nice effect if your LOAD instructions have a latency of 3,
so this should lead to performance increases, and indeed this is
what I see for some low-reg-pressure Nullstone cases. Turning
sched1 off therefore causes a regression on these cases.
However, this pipeline-type effect may increase your register
pressure such that caller-save regs are required and extra spill/fill
code needs to be generated. This happens for some other Nullstone
cases, and so it is good to have sched1 turned off for them!
It's therefore looking like some kind of clever hybrid is required.
I mention all this because I was wondering which other architectures
have turned off sched1 for -Os? More importantly, I was wondering
if anyone else had considered creating some kind of clever hybrid
that only uses sched1 when it will increase performance without
increasing register pressure?
Now onto interblock-scheduling ...
As we all know, you can't have interblock-scheduling enabled unless
you use the sched1 pass, so if sched1 is off then interblock is
irrelevant. For now, let's assume we are going to make some clever
hybrid that allows sched1 when we think it will increase performance
for Os and we are going to keep sched1 on for O2 and O3.
As I understand it, interblock-scheduling enlarges the scope of
sched1, such that you can insert independent insns from a
completely different block in between dependent insns in this
block. As well as potentially amortizing stalls on high latency
insns, we also get the chance to do "meatier" work in the destination
block and leave less to do in the source block. I don't know if this
is a deliberate effect of interblock-scheduling or if it is just
a happy side-effect.
Anyway, the reason I mention interblock-scheduling is that I see it
doing seemingly intelligent moves, but then the later BB-reorder pass
is juggling blocks around such that we end up with extra code inside
hot loops! I assume this is because the scheduler and BB-reorderer
are largely ignorant of each other, and so good intentions on the
part of the former can be scuppered by the latter.