Re: gcc-3.4.0 fails for ColdFire(does not satisfy constraints)

[Jim Wilson <wilson at specifixinc dot com>]

Ian Lance Taylor wrote:
> 	* m68k.md, alliant.md (addsi3): New alternative a=r+a, in addition
> 	to old a=a+r, needed since reload-insns are not commuted.
> As far as I know this is no longer true, and the extra alternative is
> no longer required.

We commute when reloading (input) insns, but we don't commute when 
emitting reload (output) insns.  See gen_reload () which generally just 
emits a reload the same way it was passed to it without checking for 
commutative operands.  This might be the reason why rms made this change.

gen_reload does handle the special case where we have 3 register 
operands and the second PLUS operand matches the output operand.  It 
doesn't handle the case where the first PLUS operand is a constant. 
Based on normal canonicalization rules, we shouldn't be getting (plus 
constant reg) here, but maybe there is an unusual case where this can 
happen.

I think it would be reasonable to consider this a reload bug though.

Actually, I see that current code handles SUBREG and the old gcc-2.2.2 
code does not.  Maybe that was the problem.  In which case, there still 
seems to be a bug in the current sourecs, because the the commutative 
check in gen_reload doesn't handle SUBREGs, so in theory we could still 
end up with the a=r+a case.  It will be rejected, and then we will emit 
an alternative sequence, so this will still work, but you will silently 
lose some performance because you get a less efficient reload sequence 
generated.  Again, this probably should be fixed in gen_reload rather 
than in m68k.md.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com