Problem in gen_reload(), seeking an explanation

[Franz Sirl]

Am Mon, 21 Jun 1999 schrieb Joern Rennecke:
>> Hmm, wouldn't addsi3 abort() the same way as addsi2 does now? addsi2
>> currently aborts before we can try the move/add sequence a 2nd time with the
>> operands swapped.
>
>I'm not proposing to use addsi3 itself, but just using its operand predicates.
>Or more exactly, you index add_optab->handlers with the mode of the add,
>and if the insn code you get is not CODE_FOR_nothing, you call
>(*insn_operand_predicate[icode][1])

Hmm, something like this?

--- reload1.c   1999/05/08 01:34:55     1.145
+++ reload1.c   1999/06/21 20:30:19
@@ -7819,9 +7819,13 @@ gen_reload (out, in, opnum, type)
         DEFINE_PEEPHOLE should be specified that recognizes the sequence
         we emit below.  */

+      code = (int) add_optab->handlers[(int) GET_MODE (out)].insn_code;
+
       if (CONSTANT_P (op1) || GET_CODE (op1) == MEM || GET_CODE (op1) == SUBREG
          || (GET_CODE (op1) == REG
-             && REGNO (op1) >= FIRST_PSEUDO_REGISTER))
+             && REGNO (op1) >= FIRST_PSEUDO_REGISTER)
+         || (code != CODE_FOR_nothing
+             && ! (*insn_operand_predicate[code][2]) (op1, insn_operand_mode[code][2])))
        tem = op0, op0 = op1, op1 = tem;

       gen_reload (out, op0, opnum, type);

Actually I believe this solution is way better than the regclass approach. Do I
have to guard this with a (GET_CODE (op1) == REG && REGNO (op1) <
FIRST_PSEUDO_REGISTER)?

Franz.