RE: Is eliminate_regs_in_insn allowed to generate invalid instruction?

["Bingfeng Mei" <bmei at broadcom dot com>]

> -----Original Message-----
> From: Ulrich Weigand [mailto:uweigand@de.ibm.com]
> Sent: 17 December 2010 18:48
> To: Bingfeng Mei
> Cc: iant@google.com; gcc@gcc.gnu.org; gcc-patches@gcc.gnu.org
> Subject: Re: Is eliminate_regs_in_insn allowed to generate invalid
> instruction?
> 
> 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.
> 

Thanks, that is exactly what I see. But is only EXTRA_CONSTRAINT_STR
that suffers this issue? It sounds that normal memory constraint should
have this problem too. 

> 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

Bingfeng