reload mucking with my allocation

[Daniel Berlin]

Michael Matz <matzmich@cs.tu-berlin.de> writes:

> 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.

See where i commented out find_reg_given_constraints? Hook it up to
your equivalent, tell reload you are running from global-alloc (pass 1
as the last argument instead of 0), and see if the problem goes away.

> 
> 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?

Possibly.
Call update_reg_equivs() when you are done.

Try that before doing the above.

> 
> 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?)

That's what the first suggestion i made does (when reload goes to find
a register to put something back into, that's what ti does).

> 
> Where should I look?  Or are any issues known with reload?  Should I
> provide more info?  More RTL dumps?  Anyone?


> 
> 
> Ciao,
> Michael.