Re: Patch to rework MIPS handling of SIGN_EXTENDs

[Richard Sandiford <rsandifo at redhat dot com>]

Alexandre Oliva <aoliva@redhat.com> writes:
> But I've been thinking some more about it, and I couldn't figure
> something out.  With the mips definition of OPERAND_ADDRESS, it
> appears to me that we might end up with rtx like:
> 
> (set (sign_extend:DI (reg:SI ...)) (...))
> 
> and this would be recognized and deemed valid given a pattern like:
> 
> (set (match_operand "register_operand" "=r") (...))
> 
> but I can't make sense out of this rtx...

Yeah, it would match.  But like you say, it doesn't seem to make much
sense to have SIGN_EXTEND on the left-hand side.  I assumed it was
invalid rtl, and ought never to be generated, even if it did happen
to match a pattern.  Much like we should never (AFAIK) generate
(neg:SI (set:SI ...)), or whatever.

If it's up to the md file to reject such patterns, then the patch
definitely needs some... adjustment. ;) I guess one option would be
to add a parameter to OPERAND_ADDRESS that indicated whether it was
a lhs value.

Even if it turns out not to be necessary for the MIPS, would it
be useful for SH5?  (Or any other port?)

Richard