RFC [reload1] maybe share op_addr reloads

[DJ Delorie]

Hmmm... I theorize that if a target has as many address registers as
operands in an opcode, it must be possible to reload it somehow.

The reloads do have the operand number encoded; I did check for that.
The only case would be two opaddr reloads which reflect the same rtl
but are used for two operands, but wouldn't reload treat them
individually?  One reload can't have to opnum's.

Anyway, if we can ensure that the reload that the register is shared
with is emitted later than the conflicting ones, then the needed
register is still live.

Could we add a field to rld[] that lets us keep track of which opaddrs
go with which operands?

Unless there's a better way of managing this situation for m32c.  I
did try reloading $fp to an address register, which would have given
us a much easier situation, but I couldn't convince gcc to not also
reload the whole address too. 160[fp] is not a valid address, but if
we know fp will be copied to a0, where 160[a0] is valid, we could say
it's OK, but then we don't get a chance to validate 160[fp] in the
first place.  Sigh.