AM30/AM33: global simplification and standardization of patterns

[Alexandre Oliva]

On Apr 25, 2000, Jeffrey A Law <law@cygnus.com> wrote:

> For example I would have gone after the integer moves as one hunk, then the
> FP moves, then the comparisons, then arithmetic, then logicals, then shifts,
> etc.

Yep, I've started doing that on Sunday, but I got ill yesterday and
couldn't proceed with it.  I found very surprising results right in
the very first insn.  Even though the `x' class now maps to NO_REGS on
non-AM33, removing references to `x' from the mn10300 movqi pattern
causes code size to increase.  I haven't investigated yet, but would
you have any guess of a reason?

> Sounds like more work and it is.  But you would have a much better idea of
> what change is causing your code size increases than you do right now.

Yup.

> It also isn't necessarily a good idea to combine alternatives like you have;
> I believe that can make a difference in register class preferencing, though
> I'm not 100% sure.

I think I can understand when it makes a difference.
REGISTER_MOVE_COST, as it is currently defined, will only compare the
basic register classes.  Any other composite classes will end up with
incorrect results.  Hopefully, the scores of the basic classes would
always be smaller than those of the composite classes, and we'd never
get the scores of the composite classes used to select register
preferences.  However, if their scores ever become lower or equal to
those of the composite classes, we might be out of luck.

>> (define_insn ""
>> -  [(set (match_operand:QI 0 "general_operand" "=dx,*a,dx,*a,dx,*a,dx,*a,dx
>> ,m")
>> -	(match_operand:QI 1 "general_operand" "0,0,I,I,a,dx,dxi,ia,m,dx"))]
>> +  [(set (match_operand:QI 0 "general_operand" "=d*a,d,da,d,m")
>> +	(match_operand:QI 1 "general_operand" "0,I,dai,m,d"))]
> You can no longer clear an address register effectively after this change.
> That may be part of the problem.  You did the same thing to several other
> patterns.

That's because the `a' case would already use the generic `mov'
pattern, not `clr', since `clr a0:3' was not available on mn10300 and
it's more expensive than `mov 0, a0:3' on AM33.

> "r" was used here for a reason.  Constraints on the reload_XXX patterns
> have special meanings, read the section on secondary reloads in the
> GCC manual.  This might also be affecting code size on the mn103/am30.

Thanks, will do.

-- 
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