Problem in gen_reload(), seeking an explanation

[Franz Sirl]

At 07:11 22.06.99 , Jeffrey A Law wrote:
>   In message < 99062122402601.00461@ns1102.munich.netsurf.de >you write:
>   > 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 
> predica
>   > tes.
>   > >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?
>[ ... ]
>Much better :-)  No mucking around with regclasses and generally cleaner.
>
>Basically the updated patch says "if op1 is not a suitable operand for an
>add instruction, then try to reload it into a suitable add operand".  Which
>is what we really want to happen.
>
>ie, we can reload either OP0 or OP1 into OUT.  We want to reload the one that
>is not a valid add operand.  If neither is a valid add operand, then, well
>we've got a real problem :-)  I do not think we need to worry about hard vs
>pseudo regs here for this case
>
>Did the revised patch fix your problem?

Yes, the problem is fixed with this patch :-). No testsuite regressions. 
This was a difficult one. What should I write in the comment Jörn requested?

Franz.