AM30/AM33 SP handling

[Jeffrey A Law]

  In message < or3doae7t3.fsf@zecarneiro.lsd.ic.unicamp.br >you write:
  > On Apr 24, 2000, Jeffrey A Law <law@cygnus.com> wrote:
  > 
  > >   In message < or7ldo3mm0.fsf@zecarneiro.lsd.ic.unicamp.br >you write:
  > 
  > >> Registers 23 and 31 shouldn't get in trouble because they can only be
  > >> allocated to DATA_OR_ADDRESS_REGS; register 26 is the one that
  > >> requires SP_OR_ADDRESS_REGS, else DATA_OR_ADDRESS_REGS.
  > 
  > > This is the first hint of a problem.  SP_OR_ADDRESS_REGS?!?
  > > Why would we even consider SP for any register anyway.
  > 
  > > I believe you'll find the regclass info dumped in the .lreg file.
  > 
  > Well, there is this SP_REGS class that is quite suitable for a
  > register used in a MEM, as register 26 is.
OK.  I suspect this happens because we consider SP a valid base
register - see the calls to record_address_regs in regclass and
how they use BASE_REG_CLASS.

  > And then, since
  > ADDRESS_REGS and SP_REGS have the same cost, regclass picks their
  > union:
  > Pass 0
  > 
  >   Register 26 costs: NO_REGS:0 DATA_REGS:6 ADDRESS_REGS:0 SP_REGS:0 DATA_OR
  > _ADDRESS_REGS:12 SP_OR_ADDRESS_REGS:18 EXTENDED_REGS:24 DATA_OR_EXTENDED_RE
  > GS:24 ADDRESS_OR_EXTENDED_REGS:24 SP_OR_EXTENDED_REGS:24 SP_OR_ADDRESS_OR_E
  > XTENDED_REGS:24 GENERAL_REGS:24 ALL_REGS:24 MEM:15
  > 
  >   Register 26 pref SP_OR_ADDRESS_REGS, else DATA_OR_ADDRESS_REGS
  > 
  > Pass 1
  > 
  >   Register 26 costs: NO_REGS:30 DATA_REGS:36 ADDRESS_REGS:30 SP_REGS:30 DAT
  > A_OR_ADDRESS_REGS:42 SP_OR_ADDRESS_REGS:48 EXTENDED_REGS:54 DATA_OR_EXTENDE
  > D_REGS:54 ADDRESS_OR_EXTENDED_REGS:54 SP_OR_EXTENDED_REGS:54 SP_OR_ADDRESS_
  > OR_EXTENDED_REGS:54 GENERAL_REGS:54 ALL_REGS:54 MEM:45
  > 
  > Register 26 used 4 times across 38 insns in block 0; set 2 times; crosses 7
  >  calls; pref SP_OR_ADDRESS_REGS, else DATA_OR_ADDRESS_REGS; pointer.
  >
  > > I would start by trying to figure out why SP was included in the set
  > > of registers that are preferred for reg26.  It makes me wonder if
  > > we're missing a '*' or something like that in one of the patterns or
  > > if regclass is severely messing something up.
  > 
  > In fact, there's no `*' before any `y'; it definitely helps in this
  > case.  In fact, it does indeed fix the problem.  So, I propose to
  > modify the patch I posted before so that, instead of adding a `!' to
  > the `y' alternatives, we just insert a `*' before the `y's.  It does
  > fix the problem.
  > 
  > But wouldn't there still be a risk that reload decided to choose SP
  > for some register, that the `!'s would avoid?  I.e., would it make
  > sense to keep the `!' in the `y' alternatives as I had proposed?
  > Whatever the choice, ok to install?
You would probably want to use '!' as the first constraint character in
any alternative which includes 'y', and a '*' in front of 'y' itself.

That should do two things.

First, the '!' means we will only select that alternative if it fits without
needing any reloads.  The '*' "hides" the SP_REGS class from the register
preferencing code.  The combination of the two ought to fix this problem.

I can't think of a case on the mn103 where reload would select SP for a
spill reg -- if it did, we'd get an abort because SP is a fixed register.
That would indicate either a bug in register allocation/reloading or a bug
in the mn103 backend (as is the case with the bug you're fixing right now).

The situation isn't significantly different than any other port we support --
the only differences is the limited size of the mn103 register file means
a bug in the register allocators or backend will tend to expose itself
more readily because there are fewer hard registers available to the 
allocator & reloader.


jeff