Re: Is eliminate_regs_in_insn allowed to generate invalid instruction?

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Bingfeng Mei wrote:

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

As Ian said, since the address wasn't *completely* reloaded (so that
after reload we'll have just a plain base register), it is correct
that address_reloaded must be 0.

However, if you're running into problems in this part of the code, you
may probably hit another of the long-standing warts in reload: at this
point, you have an address that reload has already decided to reload
certain parts of, and the result has to match one of your port's
extra memory constraints.  However, reload at this point has not
actually made any modifications to the address in its RTL form, it
has just recorded in its own tables that *later*, it *will* replace
some subexpressions of that RTL with registers.

This means that the RTL that is passed to your EXTRA_CONSTRAINT_STR
implementation will still be the *original* un-reloaded address.
And most likely, your back-end will then reject this address as
not valid for your machine.

The way some ports take around this issue is to recognize, in your
EXTRA_CONSTRAINT_STR implementation, certain forms of complex
addresses as those which you *know* reload will already have marked
for reloading, and therefore *accept* them (if they'd otherwise
match the constraint).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com