Is eliminate_regs_in_insn allowed to generate invalid instruction?

[Ian Lance Taylor]

"Bingfeng Mei" <bmei@broadcom.com> writes:

> I think I found the cause. find_reloads_address returns 0 even
> it reloads both parts of address (see the patch). Therefore, 
> corresponding address_reloaded[i] is not set and in
> the following code of find_reloads, 
>
>    if (EXTRA_CONSTRAINT_STR (operand, c, p))
>     win = 1;
> /* If the address was already reloaded,
>    we win as well.  */
>    else if (MEM_P (operand)
> 	      && address_reloaded[i] == 1) <-- address_reloaded[i] still 0
>      win = 1;
>     ...
>
> Extra reload is thus generated even it is unnecessary
> and causes ICE. 
>
> It looks like a general GCC bug. But I couldn't produce
>  a test for x86. The following patch is bootstrapped 
> and passes tests on x86_64-unknown-linux-gnu. Is it
>  OK to apply the patch?
>
> Cheers,
> Bingfeng 
>
>
> Index: reload.c
> ===================================================================
> --- reload.c    (revision 167979)
> +++ reload.c    (working copy)
> @@ -5188,7 +5188,7 @@ find_reloads_address (enum machine_mode
>                                   &XEXP (ad, 1 - op_index), opnum,
>                                   type, 0, insn);
>
> -         return 0;
> +         return 1;

I'm willing to believe that there is a problem here, but that patch
isn't right.  find_reloads_address should only return 1 if the address
is replaced or reloaded as a whole, and that is not what is happening
here.  What is happening here is that the components of the address are
being reloaded.

Frankly I would fix this problem in LEGITIMIZE_RELOAD_ADDRESS.

Ian