This is the mail archive of the gcc-patches@gcc.gnu.org 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


On Fri, Dec 08, 2006 at 06:15:14PM +0100, Ulrich Weigand wrote:
> Michael Matz wrote:
>> The constraints in that instruction seem to not forbid reg 65.  Hence
>> global (in fact regclass.c) has no reason to believe that it can not be
>> used for that operand (the register allocator is driven only by the
>> constraints as far as register classes are concerned).  The predicate must
>> not reject registers which the constraints accept.  If for some reason you
>> need to reject some hardregs already in the predicate then you need to
>> create a new register class which also excludes that register and use that
>> in the constraints.
> 
> That's what I thought at first, but operand 0 in *addsi3_internal has
> only 'r' as constraint, which should be interpreted as GENERAL_REGS,
> and that class does not contain reg 65 ...
> 
> Any idea why global/regclass might not respect that?

It seems that this is normal.  Debugging the unpatched compiler, we get
exactly the same rtl insn (below) passed into eliminate_regs_in_insn as we
do with the patched compiler.  The difference is that the unpatched compiler
doesn't attempt to call recog on the insn and doesn't have an gcc_assert.

(insn:HI 139 120 244 3 (set (reg/f:SI 65 lr [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)))

With the unpatched compiler, looking in the rtl dumps (which I've made
available at http://www.bergner.org/gcc/reload-base/ ), we can see that
sometime after the call to eliminate_regs_in_insn, insn 139 is split into
the insns below (I've included the relevant portions of the glocal-alloc
rtl dump.

So I'm guessing, we need to just let this insn pass by without trying
to call recog() on it?

Peter



;; 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
[snip]
init_insns for 238: (insn_list:REG_DEP_TRUE 139 (nil))
[snip]
Spilling for insn 139.
Using reg 0 for reload 0
[snip]
Reloads for insn # 139
Reload 0: reload_out (SI) = (reg/f:SI 65 lr [238])
        GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
        reload_out_reg: (reg/f:SI 65 lr [238])
        reload_reg_rtx: (reg:SI 0 0)
[snip]
;; Register dispositions:
..  238 in 65
[snip]

(insn:HI 139 120 283 3 (set (reg:SI 0 0)
        (plus:SI (reg/f:SI 1 1)
            (const_int 12 [0xc]))) 79 {*addsi3_internal1} (nil)
    (expr_list:REG_EQUIV (plus:SI (reg/f:SI 1 1)
            (const_int 12 [0xc]))
        (nil)))

(insn 283 139 244 3 (set (reg/f:SI 65 lr [238])
        (reg:SI 0 0)) 323 {*movsi_internal1} (nil)
    (nil))



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