This is the mail archive of the
mailing list for the GCC project.
Re: More general patch for "mips offs > 16bit", (emit_insn/force_operand inconsistencies, expr.c 1.76).
- To: Hans-Peter Nilsson <hp at bitrange dot com>
- Subject: Re: More general patch for "mips offs > 16bit", (emit_insn/force_operand inconsistencies, expr.c 1.76).
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Wed, 10 Mar 1999 03:15:52 -0700
- cc: egcs-patches at egcs dot cygnus dot com, pefo at opsycon dot se, jonathan at DSG dot Stanford dot EDU
- Reply-To: law at cygnus dot com
In message <Pine.BSF.4.02A.firstname.lastname@example.org>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.