This is the mail archive of the gcc-patches@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: AM30/AM33 SP handling


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.  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_REGS:24 ADDRESS_OR_EXTENDED_REGS:24 SP_OR_EXTENDED_REGS:24 SP_OR_ADDRESS_OR_EXTENDED_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 DATA_OR_ADDRESS_REGS:42 SP_OR_ADDRESS_REGS:48 EXTENDED_REGS:54 DATA_OR_EXTENDED_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?

-- 
Alexandre Oliva    Enjoy Guaranį, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me


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