This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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?


  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]