Vladimir Makarov wrote:
...
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
Daniel Jacobowitz wrote:
...
Not even a single comment - shame on you both! :-) If this is the
solution we choose, can we make sure that there's at least a comment
explaining what's going on?
Totally agree. That was an *example patch*. Here is a bit updated, but
still an example of how
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
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
On Tue, May 30, 2006 at 08:57:57PM +0200, Paolo Bonzini wrote:
int
default_reorder2 (FILE *dump ATTRIBUTE_UNUSED,
int sched_verbose ATTRIBUTE_UNUSED,
rtx *ready, int *pn_ready,
int clock_var ATTRIBUTE_UNUSED)
{
int n_ready = *pn_ready;
Hi Maxim and Vlad,
I just tracked an ICE while building glibc for ARM to this patch,
which introduced --param max-sched-extend-regions-iters with a default
of two:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00998.html
The testcase is attached; an arm-linux-gnueabi compiler should be able to
