Re: [m32c] newlib build failure in reload

[DJ Delorie <dj at redhat dot com>]

> You should file a PR in any case.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827

> Does m32c handle some addresses specially in any way at all similar to the 
> special SH handling discussed in PR 36780 and 
> <http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00932.html>?  Because some 
> sort of inconsistency about when addresses are valid seems to be involved 
> in some way in that problem (with consistency, I'd have expected cases 
> where my patch is relevant to have caused problems before the patch as 
> well).  If there does turn out to be a target-independent patch relevant 
> to fixing the SH issue, it might be relevant to the m32c issue as well.

m32c has a number of interesting (and non-orthagonal) addressing
modes.  It does have a load-effective-address opcode, but the index
reg is limited to A0, A1, or FB (8bit), and the destination is limited
to R0..R3 or A0..A1.  Otherwise it has add2 but not add3.  Conditional
jumps are kept as one insn until after reload to ensure that reload
doesn't corrupt the flags.

The usual m32c problem (not implying that *this* problem is the same)
is thusly:

The frame pointer only has an 8 bit signed displacement.  $sp is
worse.  So we end up reloading a *lot* of frame pointers to the two
address registers, $a0 and $a1.  Unfortunately, gcc is not very good
at this - it often finds itself with three reloads to deal with and
only two address registers, and isn't smart enough to do the math in
the right order (or take advantage of the displacements to combine
pointers) to keep from needing three physical address registers.

I did some work a while back to try to rearrange the reloads so that
registers could be reused, but IMHO the right solution is for gcc to
realize that it needs to break the insn up and reload the parts
separately, perhaps a "relaxing reloader" that can restart reload if
it finds it has run short of registers.