More general patch for "mips offs > 16bit", (emit_insn/force_operand inconsistencies, expr.c 1.76).

[Jeffrey A Law]

  In message <Pine.BSF.4.02A.9902281014211.23099-100000@dair.pair.com>you write
:
  > So here we go again.  At that time (1996), there were constructs
  > like "emit_move_insn (return_val_rtx, plus_constant (temp, -8));",
  > (fixed since long it seems). 
Good since that's generally wrong.

  > Now there are force_reg constructs where an operand can be an address;
  > similar to that above, but not as obvious.  Since emit_move_insn is
  > called with that unmodified operand, the effect is just as bad, unless
  > optimization is on, doing transformations that make it recognized.
While I agree that we should not be calling emit_move_insn with a source
operand that is not a reg/mem/const, it does not necessarily mean that the
emit_move_insn call site is the culprit.

Each instance needs to be analyzed.  ie, how did we end up passing a
bogus operand to these functions.  Should that operand have been handled
by code earlier in the call path?


  > I'm not completely sure what TRT is here.  At that time, I
  > thought that emit_move_insn should always be called with a valid
  > operand (that is, through force_operand if necessary).
emit_move_insn should only be called with regs, subregs, mems and
constants as far as I can remember.  If you look at emit_move_insn_1 it tries
to use mov_optab to generate the move.  Which will (almost always) map to
the movXX patterns.

Calling it with (plus (reg) (const_int)) is a bug.  But you have to do the
analysis to find out why it was called with that expression.

  >  On the other hand, there's force_operand that does this job,
  > and is used in a lot of places just before calling
  > emit_move_insn or force_reg.
Yes.  Typically this is done in those cases where we know that it's the
right thing to do -- after analysis determines that in fact it is valid
to have a complex operand at that point in the code.

  > But again on the first hand, not
  > all uses of an asserted operand is to call emit_move_insn.  And
  > it seems better to fix the called function than all the callers
  > (even though *most* are correct as it is).
No.  It's better to actually analyze the code and determine where they're
needed.  That's what I think we need to do for this problem.

I suspect when we do that we'll find that by exposing addressing modes that
don't actually exist is the root of the problem.

jeff