This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug
On Fri, Dec 08, 2006 at 02:13:54PM +0100, Ulrich Weigand wrote:
> Andrew Pinski wrote:
> > 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?
Ok, I stripped the test case down a little, so the insn number has changed from
176 to 139 and the pseudo has changed from 235 to 238. I have also made the
test case and the rtl dumps available at: http://www.bergner.org/gcc/reload/
The insn after local-alloc looks like:
(insn:HI 139 120 244 3 (set (reg/f:SI 238)
(plus:SI (reg/f:SI 113 sfp)
(const_int 12 [0xc]))) 79 {*addsi3_internal1} (nil)
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 113 sfp)
(const_int 12 [0xc]))
(nil)))
Yes, it seems strange that pseudo 238 should be allocated to the link reg.
>From the global-alloc dump (from what little it there before we died), we
have this info for pseudo 238:
;; 238 conflicts: 153 154 155 156 157 158 159 160 162 163 164 165 166
170 171 172 173 174 175 176 177 178 180 182 184 185
186 187 188 190 191 192 194 196 197 199 207 208 209
210 211 212 213 214 216 218 220 222 223 229 230 231
233 235 237 238 239 240 241 242 243 244 0 1 9 10 11
75
I'll continue to look at why global-alloc allocated 238 to hard reg 65.
I would have guessed they'd be in the conflicts list, but looking at
how few hard regs are in it, it seems to only include hard regs actually
used in the rtl and that there must be some code which I'll look for that
keeps pseudos from be ing allocated to the other hard regs they shouldn't
be allocated to.
Peter