Problem in gen_reload(), seeking an explanation
Franz Sirl
Franz.Sirl-kernel@lauterbach.com
Wed Jun 30 15:43:00 GMT 1999
At 06:59 22.06.99 , Jeffrey A Law wrote:
> In message < 4.2.0.56.19990621135045.036f9220@mail.lauterbach.com >you write:
> > The code is not shuffling operands cause it is only special-casing
> > pseudo-registers, but we enter here with 2 real registers. Something
> like
> > below works too:
>Not exactly what I had in mind. But better.
>
>If you look even earlier, you will find code that looks like this:
>
> if (op0 != XEXP (in, 0) || op1 != XEXP (in, 1))
> in = gen_rtx_PLUS (GET_MODE (in), op0, op1);
>
> insn = emit_insn (gen_rtx_SET (VOIDmode, out, in));
> code = recog_memoized (insn);
>
> if (code >= 0)
> {
> extract_insn (insn);
> /* We want constrain operands to treat this insn strictly in
> its validity determination, i.e., the way it would after reload
> has completed. */
> if (constrain_operands (1))
> return insn;
> }
>
> delete_insns_since (last);
>
>We can do the same thing in the later hunk of code. ie, try it one way, if
>that does not work, swap the operands and try again. Something like this
>
> gen_reload (out, op0, opnum, type);
>
> /* If OP0 and OP1 are the same, we can use OUT for OP1.
> This fixes a problem on the 32K where the stack pointer cannot
> be used as an operand of an add insn. */
>
> if (rtx_equal_p (op0, op1))
> op1 = out;
>
> insn = emit_insn (gen_rtx_SET ...)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You are kidding, aren't you? That's exactly what my first patch did.
> /* If that failed, copy the address register to the reload register.
> Then add the constant to the reload register. */
>
> code = recog_memoized (insn);
> [ ... check that the operands match the constraints... ]
> if constraints fail, call delete_all_insns_since (last), swap
> op0 and op1 and try again. If it still fails delete the insns and
> go on to the next method of generating the reload.
Still the same way as I suggested in my first patch.
Now, why didn't you accept my first patch?
Franz.
More information about the Gcc
mailing list