Re: Problem in gen_reload(), seeking an explanation

[Jeffrey A Law <law at cygnus dot com>]

  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?

jeff