This is the mail archive of the gcc-bugs@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]

Re: alpha [reload] bug


On Tue, Jan 19, 1999 at 10:37:27AM +0000, Joern Rennecke wrote:
> > Third, and this is the killer from this example's point of view, is
> > that emit_reload_insns creates a new reload via gen_reload.  This 
> > happens after choose_reload_regs has been called, so when we get to
> > subst_reloads, we've not got a register for the new reload and abort. 
> > This one I don't know how to solve, as I don't know how this stuff is
> > supposed to interact.
> 
> Can you elaborate on this?  How does the backtrace look, etc?

#0  push_reload (in=0x120588348, out=0x0, inloc=0x120588378, outloc=0x0, 
    class=GENERAL_REGS, inmode=DImode, outmode=VOIDmode, strict_low=0, 
    optional=0, opnum=1, type=RELOAD_FOR_INPUT_ADDRESS)
    at ../../../egcs/gcc/reload.c:800
#1  0x12019bef8 in find_reloads_address (mode=DImode, memrefloc=0x0, 
    ad=0x120588370, loc=0x120588328, opnum=1, type=RELOAD_FOR_INPUT_ADDRESS, 
    ind_levels=0, insn=0x0) at ../../../egcs/gcc/reload.c:4670
#2  0x12018db6c in get_secondary_mem (x=0x120587eb8, mode=DImode, opnum=1, 
    type=RELOAD_FOR_INPUT_ADDRESS) at ../../../egcs/gcc/reload.c:705
#3  0x1201b96cc in gen_reload (out=0x1205880e8, in=0x120587eb8, opnum=1, 
    type=RELOAD_FOR_INPUT) at ../../../egcs/gcc/reload1.c:7776
#4  0x1201b679c in emit_reload_insns (chain=0x12057f3b8)
    at ../../../egcs/gcc/reload1.c:6927
#5  0x1201ae94c in reload_as_needed (live_known=1)
    at ../../../egcs/gcc/reload1.c:4260
#6  0x1201a4794 in reload (first=0x120555ae0, global=1, dumpfile=0x0)
    at ../../../egcs/gcc/reload1.c:1046

The OUT and IN for gen_reload are (reg:DI 43 $f11) and (reg:DI 3 $3)
respectively.  Naturally, this must go through memory.

At the end of emit_reload_insns, we have

Reload 0: reload_in (DI) = (plus:DI (reg:DI 30 $30)
                                    (const_int 65536))
        GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1)
        reload_in_reg: (plus:DI (reg:DI 30 $30)
                                (const_int 65536))
        reload_reg_rtx: (reg:DI 2 $2)
Reload 1: reload_in (DI) = (plus:DI (reg:DI 30 $30)
                                    (const_int 65536))
        GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1)
        reload_in_reg: (plus:DI (reg:DI 30 $30)
                                (const_int 65536))
        reload_reg_rtx: (reg:DI 2 $2)
Reload 2: GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1),
        can't combine, secondary_reload_p
        reload_reg_rtx: (reg:DI 3 $3)
Reload 3: reload_in (DI) =
	(subreg:DI (mem:SI (plus:DI (plus:DI (reg:DI 30 $30)
                                             (const_int 65536))
                                    (const_int -7048)) 0) 0)
        FLOAT_REGS, RELOAD_FOR_INPUT (opnum = 1)
        reload_in_reg: (subreg:DI (mem:SI (plus:DI (plus:DI (reg:DI 30 $30)
                                                            (const_int 65536))
                                                   (const_int -7048)) 0) 0)
        reload_reg_rtx: (reg:DI 43 $f11)
        secondary_in_reload = 2
Reload 4: reload_in (DI) = (plus:DI (reg:DI 30 $30)
                                    (const_int 65536))
        GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 1)
        reload_in_reg: (plus:DI (reg:DI 30 $30)
                                (const_int 65536))

subst_reloads will abort processing the replacements for reload 4.

If you need more information, please ask.

> You'd have to add this use of VOIDmode to the LEGITIMIZE_RELOAD_ADDRESS
> documentation and go over all current definitions of
> LEGITIMIZE_RELOAD_ADDRESS.

Certainly. 

I suspect that the current definitions would work, because if
they are mode dependant at all, they'll already be checking the
mode, and VOIDmode won't match.

> Combining reloads too early can raise the register pressure.
> So for SMALL_REGISTER_CLASSES the preferred strategy is to keep distinct
> reloads, but allocate them to the same register and then merge them 
> in merge_assigned_reloads if that is still possible.

Oh, I see.  I hadn't considered the possibility that we might be
assigning the same hard register to multiple identical reloads.
But looking at the post choose_reload_regs debug information, this
exactly what is actually happening already.  :-)


r~


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