Re: Commit policy wrt. to-be-obsolete targets

[Ian Dall <ian at beware dot dropbear dot id dot au>]

law@redhat.com writes:

>  In message <15607.36403.110454.80366@sibyl.beware.dropbear.id.au>, Ian Dall 
> writes:
>  > The remaining problem I have is that I get an abort in find_reloads(). This 
>  > is
>  > in:
>  > 
>  >     #ifdef HAVE_cc0
>  >       /* If we made any reloads for addresses, see if they violate a
>  > 	 "no input reloads" requirement for this insn.  But loads that we
>  > 	 do after the insn (such as for output addresses) are fine.  */
>  >       if (no_input_reloads)
>  > 	for (i = 0; i < n_reloads; i++)
>  > 	  if (rld[i].in != 0
>  > 	      && rld[i].when_needed != RELOAD_FOR_OUTADDR_ADDRESS
>  > 	      && rld[i].when_needed != RELOAD_FOR_OUTPUT_ADDRESS)
>  > 	    abort ();
>  >     #endif
>  > 
>  > This is on a "seq" insn.
>  > 
>  >     (set (mem/s:SI (plus:SI (reg/v/f:SI 38)
>  > 		    (const_int 32 [0x20])))
>  > 	    (eq:SI (cc0)
>  > 		(const_int 0 [0x0])))
>  > 
>  > There seems to be a problem in the generic code in so far as it should
>  > be possible to allocate and use a memory slot (frame pointer relative)
>  > in this situation. This problem arose soon after I contributed the
>  > last lot of ns32k changes. Since it seemed to be a problem in generic
>  > code and I couldn't see how to fix it, I sort of gave up hoping that
>  > it would be fixed in due course by someone else.
> No, it's not a generic bug.  How is the compiler supposed to know that the
> cc0 value set in a previous insn is not going to be clobbered by the input
> reloads?

This is a RELOAD_FOR_OPERAND_ADDRESS. You can't reload the register because
that could change the condition codes (without some way of specifying that
it is safe). However, you can write the result to a memory slot, or
to a register, and then copy that to the final destination, ergo, no
input reload.

Maybe it is too much to expect the generic code to do that. Indeed,
what may have happened is that the generic code got better at doing
instruction combines and exposed a latent bug. It occurs to me that
maybe restricting this class of insns to register operands might
solve the problem, albeit in a sub-optimal way.

Ian