Re: RFC [reload1] maybe share op_addr reloads

[Ian Lance Taylor <ian at airs dot com>]

DJ Delorie <dj@redhat.com> writes:

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

Well, take a look at find_reusable_reload.

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

Seems OK in principle.

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

A rather desperate hack would be to use LEGITIMIZE_RELOAD_ADDRESS to
push the reload of the frame pointer using a class which will ensure
that it will get into an appropriate register, and then return the sum
with an otherwise unused virtual fixed register.  You can recognize
that virtual fixed register in GO_IF_LEGITIMATE_MEMORY_ADDRESS.  When
reload finishes, the virtual fixed register should get replaced by the
address into which the frame pointer was reloaded.

Ian