Re: Patch to rework MIPS handling of SIGN_EXTENDs

[Richard Sandiford <rsandifo at redhat dot com>]

Alexandre Oliva <aoliva@redhat.com> writes:
> > If it's up to the md file to reject such patterns, then the patch
> > definitely needs some... adjustment. ;)
> 
> Well, combine can generate very weird things, and it relies on recog
> to throw away real junk.  I don't think it would generate this kind of
> pattern, though, but it would be nice to be sure it couldn't.

I see what you mean, but if combine ever did try to generate that
sort instruction, I would have thought the right thing to do would
be to fix combine.

I realise rtl has all sorts of ways of hiding back-end details (uses,
clobbers, unspecs, ...).  But surely, in the end, it's up to each
optimisation pass to make sure that the optimised rtl has the same
behaviour?  It just seems wrong to put a non-lhs value in a lhs
context without any idea what that would mean.

For instance:

   (set (const_int 0) ...)

matches some md file patterns, since some ports use "general_operand"
as a lhs predicate.  But if combine ever generated that, it'd be a bug
in combine.

> > I guess one option would be to add a parameter to OPERAND_ADDRESS
> > that indicated whether it was a lhs value.
> 
> Hmm...  I wonder if it wouldn't be confusing if say an Input/Output
> operand were used in a match_dup, for example.

Probably ;).  It was just an off-hand suggestion really.  There's
certainly no point in adding it unless there's a known use for it.

Richard