This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: schedule_block



  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]