This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: schedule_block
- To: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>
- Subject: Re: schedule_block
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Tue, 15 Dec 1998 16:19:07 -0700
- cc: meissner at cygnus dot com, egcs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <13942.56824.799761.256729@ongaonga.elec.canterbury.ac.nz>you writ
e:
> Jeffrey A Law writes:
> > There is no way to do it, nor should there be a need.
> >
> > If the copy out of the arg register is on the critical path, then it sho
> uld
> > issue as early as possible because the copy will have a high priority.
>
>
> Here's a typical example that I've been having problems with.
>
> The meat of this function is insn 34 which requires pseudo 41 to be
> allocated to either hard register r2 or r3.
>
> The scheduler ends up moving insn 15, which zeroes pseudo 41, to be the
> first insn in the function. Since r2 and r3 are used for function
> arguments, there is no way that the register allocator can then
> allocate either r2 or r3 to pseudo 41.
I don't see any generic way to fix this. It is an unfortunate effect that
scheduling and register allocation have bad interactions. Such is life until
someone donates a combined allocator and scheduler.
You could do something with MD_* macros, though I would recommend against it.
*Typically* when you override the scheduling rules you will get worse code,
that's been my experience. You may get locally better code, but generally
you lose.
I'm also not sure it is safe for the c4x to enable scheduling before
allocation. You seem to have classes for pairs of regs which also show
up explicitly in the RTL. See recent thread about %eax usage on the
x86.
Sorry,
jeff