Mark Mitchell wrote:
David Edelsohn wrote:
Maxim Kuvyrkov writes:
Maxim> Anyway, this work is for stage 1 or 2 and for now I propose following
Maxim> fix: implement targetm.sched.reorder hook so that it will ensure that if
Maxim> there is an insn from the current block in the ready list, then insn
Maxim> from the other block won't stand first in the line (and, therefore,
Maxim> won't be chosen for schedule). I feel that this will be what you are
Maxim> calling 'filling holes'. Please find an example patch attached (arm.patch).
What about all of the other GCC targets?
If your patch changed the default behavior of the scheduler
assumed by all other ports, you should fix the scheduler and modify the
IA-64 port to get the behavior desired.
Exactly.
I think this is a serious regression, and I would like to consider our
options. Daniel has suggested changing the default value of the
max-sched-extend-regions-iters param to 1. However, I think we should
conservatively change it to zero, for now, and then use a target macro
to allow IA64 to set it to two, and other ports to gradually turn this
on if useful.
I am agree with this. Two months ago Maxim submitted patches which
affects only ia64 except one thing affecting all targets - the patch
which builds more scheduling regions and as consequence permits more
aggressive interblock scheduling.
Insn scheduling before the register allocation even without Maxim's
patches is not safe when hard registers are used in RTL. It is a known
bug (e.g. for x86_64) and it is in bugzilla. Jim Wilson wrote several
possible solutions for this, no one is easy to implement except for
switching off insn scheduling before RA (what is done for x86_64).
But we can restore the state (probably safe for most programs) what was
before Maxim's patch. So Maxim could you do this (of course you can
save max-sched-extend-regions-iters value for ia64 because it is
probably safe for targets with many registers).
Vlad
