Re: RFC [reload1] maybe share op_addr reloads

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

DJ Delorie <dj@redhat.com> writes:

> This comment seems to explain why:
> 
>   /* Scan all the reloads, and check for RELOAD_FOR_OPERAND_ADDRESS reloads.
>      If we have more than one, then convert all RELOAD_FOR_OPADDR_ADDR
>      reloads to RELOAD_FOR_OPERAND_ADDRESS reloads.
> 
>      choose_reload_regs assumes that RELOAD_FOR_OPADDR_ADDR reloads never
>      conflict with RELOAD_FOR_OPERAND_ADDRESS reloads.  This is true for a
>      single pair of RELOAD_FOR_OPADDR_ADDR/RELOAD_FOR_OPERAND_ADDRESS reloads.
>      However, if there is more than one RELOAD_FOR_OPERAND_ADDRESS reload,
>      then a RELOAD_FOR_OPADDR_ADDR reload conflicts with all
>      RELOAD_FOR_OPERAND_ADDRESS reloads other than the one that uses it.
>      This is complicated by the fact that a single operand can have more
>      than one RELOAD_FOR_OPERAND_ADDRESS reload.  It is very difficult to fix
>      choose_reload_regs without affecting code quality, and cases that
>      actually fail are extremely rare, so it turns out to be better to fix
>      the problem here by not generating cases that choose_reload_regs will
>      fail for.  */

Oh yeah.

> This extremely rare case happens to be the case that's failing for
> m32c :-P
> 
> Maybe we can conditionalize the new logic with SMALL_REGISTER_CLASSES?

I find it hard to believe that your patch is correct.  If you have two
reloads with type RELOAD_FOR_OPERAND_ADDRESS, then they can conflict.
That's more or less the point of the comment above.  You are trying to
detect a particular case in which they don't conflict.  But it's not
going to work in some complicated scenario in which the same address
is reloaded twice for two different operands--you're might wind up
blowing away the address of the second one.  Maybe that can't happen
for some reason, but I don't see anything preventing it.

A different approach might be to try to obviate the comment, by
somehow recording which RELOAD_FOR_OPADDR_ADDRESS corresponds to which
RELOAD_FOR_OPERAND_ADDRESS.  If you do that, then you can check it in
reloads_conflict, and you won't be forced to convert OPADDR_ADDRESS to
OPERAND_ADDRESS.  But that might get pretty tricky in some cases.

I don't have a better idea off hand.

Ian