Re: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Andrew Pinski wrote:
> On Thu, 2006-12-07 at 16:52 -0600, Peter Bergner wrote:
> > We end up in the modified code below with the "eliminated" insn now looking
> > like:
> > 
> > (insn:HI 176 157 267 4 (set (reg/f:SI 65 lr [265])
> >         (plus:SI (reg/f:SI 1 1)
> >             (const_int 12 [0xc]))) 79 {*addsi3_internal1} (nil)
> >     (expr_list:REG_EQUIV (plus:SI (reg/f:SI 113 sfp)
> >             (const_int 12 [0xc]))
> >         (nil)))
> > 
> > So we haven't eliminated the regs in the REG_EQUIV note.  We then die in
> > the gcc_assert (INSN_CODE (insn) >= 0).  I thought it might be due to
> > the REG_EQUIV not be "eliminate"'d before calling recog, but that doesn't
> > seem to be the case, since I used to debugger to manually eliminate it
> > before calling recog(), and we still end up dying.  Any idea what's
> > wrong now?
> 
> We don't cause an extra reload to happen as you cannot set the lr via an
> add.  But that instruction seems weird in general as why are we storing
> r1+12 inside the lr when we can recalulate that when we would use lr.

Extra reloads would happen if this were just a matter of an unsatisfied
constraint.  But we're just recognizing the insn here, we don't even
look at the constraints.  However, it would appear that the *addsi3_internal1
pattern rejects LR already in the operand *predicate*:

(define_insn "*add<mode>3_internal1"
  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r,r,?r,r")
        (plus:GPR (match_operand:GPR 1 "gpc_reg_operand" "%r,b,r,b")
                  (match_operand:GPR 2 "add_operand" "r,I,I,L")))]

(define_predicate "gpc_reg_operand"
   (and (match_operand 0 "register_operand")
        (match_test "(GET_CODE (op) != REG
                      || (REGNO (op) >= ARG_POINTER_REGNUM
                          && !XER_REGNO_P (REGNO (op)))
                      || REGNO (op) < MQ_REGNO)
                     && !((TARGET_E500_DOUBLE || TARGET_SPE)
                          && invalid_e500_subreg (op, mode))")))


Now the really weird thing is, operand 0 was LR even before the call
to eliminate_regs_in_insn.  How come we've got an insn that isn't
even recognizable in the insn stream?

Peter, can you try to investigate how insn 176 got into that form?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com