This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
reload mucking with my allocation
- To: <gcc at gcc dot gnu dot org>
- Subject: reload mucking with my allocation
- From: Michael Matz <matzmich at cs dot tu-berlin dot de>
- Date: Sat, 24 Feb 2001 05:32:38 +0100 (MET)
Hi,
this is a question about reload choosing a hard-reg as reload reg, which
is still needed later, without saving it in any way.
I'm not too sure how to ask the things I want to ask, without throwing out
to much verbosity, so I just present the symptoms of my problem.
Remember, that I talk about the new-regalloc branch. As that I do not run
local/global alloc at all. I only set up the reg_renumber[] array, and
call reload(0) (after doing some liveness analysis, and register class
choosing). This mostly works, but not in the following case (which is
stripped down RTL from flow.c:flow_depth_first_order_compute):
This is a part of the RTL given to reload, somewhat heavily edited. It's
produced by -O0 -g compilation. For -O2 this does not happen. I haven't
analyzed if just this constellation is not happening, or reload is really
behaving different:
(insn 155 153 157 (set (reg:SI 189) (f(reg:SI 188)))
(expr_list:REG_DEAD (reg:SI 188)
(expr_list:REG_EQUAL (udiv:SI (reg:SI 82) (const_int 32 [0x20]))))
(insn 157 155 159 (set (reg:SI 190) (reg:SI 189)))
(insn 159 157 161 (set (reg:SI 191) (f(reg:SI 190)))
(expr_list:REG_DEAD (reg:SI 190)
(expr_list:REG_EQUAL (mult:SI (reg:SI 80) (const_int 4 [0x4]))))
(insn 163 161 165 (set (reg:SI 193) (reg:SI 192))
(expr_list:REG_DEAD (reg:SI 192)))
(insn 165 163 167 (set (reg:SI 194) (mem:SI (frame-20)))
(insn 167 165 169 (set (reg:SI 195) (reg:SI 189))
(expr_list:REG_DEAD (reg:SI 189)))
(insn 169 167 171 (set (reg:SI 196) (f(reg:SI 195)))
(expr_list:REG_DEAD (reg:SI 195)
(expr_list:REG_EQUAL (mult:SI (reg:SI 80) (const_int 4 [0x4]))))
The relevant reg_renumber[] part is:
189 to 0, 190 to 0, 191 to 2, 192 to 1, 193 to 1, 194 to 3, 195 to 0 and
196 to 4.
To make it easier for a reader to see what is important here: insn 157
copies: (190<--189), then 189 is _not_ changed, copied again in
insn 167: (195<--189), where it dies. All three regs get mapped to the
same hardreg (0), so in fact reg 0 is needed until insn 167 at least.
Now when reload is called, it sees an instruction (later and not shown),
which needs hardreg 2 (its a shift instruction). reg 191 (set above in
insn 159 and mapped to reg 2) is live at that point, so reload decides to
put 191 on stack. That reg getting hardreg 2 is also live over insn 159.
Up to now everything is OK. Now it comes to creating the reloads for each
instruction. For insn 159 above this needs to be a store into the stack
slot. For this a register is needed to hold the result of the set (I
called it f(reg:SI 90) above) which then can be stored into the stack.
And here is the problem: reload chooses hardreg 0 as this reload reg.
Although it clearly is live at insn 159 (due to pseudo 189). There are
other hardregs which are not live at this point. I don't even know, where
to start looking in reload*.c.
Is there some other thing which needs to be set up for reload to work?
live-information really is accurate (I do just before reload a complete
liveness analysis pass). REG_DEATH/UNUSED notes also (because of liveness
analysis). The only thing which is left broken by new regalloc are the
REG_EQUIV/EQUAL notes. They still point to the same old pseudos which
were in use before allocation (they are not at all used after that in any
insn. Only in those notes. Above e.g. there are notes pointing to pseudo
80, which isn't used anywhere in the RTL besides of these notes.) Might
that be a reason for reload to be confused?
Is there anything in reload, where I can say, on these insns don't use
these hard-regs? (I suppose that exists, but can this get confused?)
Where should I look? Or are any issues known with reload? Should I
provide more info? More RTL dumps? Anyone?
Ciao,
Michael.