------- Comment #5 from nickc at redhat dot com 2008-03-26 14:16 -------
Subject: Re: Problem while compiling gcc for mn10300-elf
Hi Jeff,
> What does CLASS, MODE and IN look like?
Err, presumably you are talking about these values when
default_secondary_reload() triggers the abort ?
The CLASS is DATA_OR_EXTENDED_REGS.
The MODE is SImode.
IN looks like this:
(plus:SI (reg/f:SI 9 sp)
(const_int 1100 [0x44c]))
> And more interesting, what are
> all the forms IN, CLASS & MODE might be at this point?
Hmm, well I only ever saw this problem for the case in
mn10300_secondary_reload_class() that handles additions to the stack
pointer, so I think that we can say that IN will always be:
(plus (reg sp) (...))
or (plus (...) (reg sp))
CLASS is going to be DATA_REGS or DATA_OR_EXTENDED_REGS depending upon
whether we are compiling for an AM33 or an MN10300. (I have seen the
problem for both targets). MODE I assume will always be SImode. Do we
ever make stack adjustments in other modes ?
> Given the way
> the code is written, we must have thought one particular case required a
> secondary register that was a DATA_REG, presumably because an
> ADDRESS_REG wouldn't work. Your change would likely break that case.
I think it was because the stack adjustment was too large for it to be
handled as part of the addressing mode, and so a data reg was needed in
order to be able to perform the arithmetic on the stack pointer.
> It's also unclear to me that this really solves the problem as opposed
> to just papering over the problem.
Well the other approach it seems to me would be to change the class of
the scratch register in the reload_insi pattern to be "=dx&" in order to
match the possible register classes returned by
mn10300_secondary_reload_class(). I did not try this as I was worried
about changing a pattern that is going to influence a lot of other code
generation, not just stack adjustments.
> Aren't DATA_OR_EXTENDED_REGS and DATA_REGS subclasses of GENERAL_REGS
Yes
> and thus ought to work just fine given the constraints of reload_insi's
> clobber operand? "=&r"
No because the assert at line 649 of targhooks.c says that the class of
the scratch register must be the same as the class from which we are
choosing a secondary reload register. But the class of the
reload_insi's clobbered operand is GENERAL_REGS whereas the class from
which we are selecting a register is DATA_OR_EXTENDED_REGS. I agree
that this class is a subset of GENERAL_REGS, but the assert does not
allow for this. Maybe it should, but I was very loath to change a piece
of generic reload code for what seemed to be a MN10300 specific problem.
I interpreted the assert as saying "if this assert is triggered, the
target has a discrepancy between the register class returned by
SECONDARY_RELOAD_CLASS and the reload_{in|out}<mode> pattern for that
target".
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
