Re: Question on scan_one_insn in IRA about load parameters from stack slot.

[Vladimir Makarov <vmakarov at redhat dot com>]

On 04/26/2012 04:49 AM, Bin.Cheng wrote:
> On Wed, Apr 25, 2012 at 10:46 PM, Vladimir Makarov<vmakarov@redhat.com>  wrote:
> > On 04/24/2012 11:56 PM, Bin.Cheng wrote:
> > > Hi,
> > > In scan_one_insn, gcc checks whether an insn loads a parameter from
> > > its stack slot, and then
> > > record the fact by decrease the memory cost.
> > >
> > > What I do not understand is the check condition like below checks the
> > > REG_EQUIV note, rather than
> > > checking memory access using stack pointer directly.
> > >
> > >    if (set != 0&&    REG_P (SET_DEST (set))&&    MEM_P (SET_SRC (set))
> > >
> > >        &&    (note = find_reg_note (insn, REG_EQUIV, NULL_RTX)) != NULL_RTX
> > >        &&    ((MEM_P (XEXP (note, 0)))
> > >           || (CONSTANT_P (XEXP (note, 0))
> > >         &&    targetm.legitimate_constant_p (GET_MODE (SET_DEST (set)),
> > >                                                 XEXP (note, 0))
> > >         &&    REG_N_SETS (REGNO (SET_DEST (set))) == 1)))
> > >
> > > So what's the connection between REG_EQUIV and stack slot for
> > > parameters? I noticed from
> > > below dumps of IRA pass, seems the annotated insn is not load
> > > parameter from stack, but it is
> > > treated as the check condition. Why?
> > >
> > > Dump of IRA:
> > >
> > > (insn 121 118 122 6 (set (reg/f:SI 252 [ l_curve ])
> > >          (mem/f/c:SI (reg/f:SI 230) [7 l_curve+0 S4 A32]))
> > > bezier01/bmark_lite.c:246 186 {*thumb1_movsi_insn}
> > >       (expr_list:REG_EQUIV (mem/f/c:SI (reg/f:SI 230) [7 l_curve+0 S4 A32])
> > >          (expr_list:REG_EQUAL (mem/f/c:SI (symbol_ref:SI ("l_curve")
> > > [flags 0x80]<var_decl 0xb768d0c0 l_curve>) [7 l_curve+0 S4 A32])
> > >              (nil))))
> > >
> > >
> > > I am not sure if I missed something important, please help. Thanks very
> > > much.
> > Reload uses equivalent memory (not an allocated stack slot) if the pseudo
> > did not get a hard registers.  Therefore the equivalent insns for the pseudo
> > (they can be more than one) are not necessary and removed and that decreases
> > memory cost.  Many cases contain loading parameters from the stack.  But
> > there are a lot of other cases too.
> Thanks for explaining.
Sorry for the answer delay.  I was on vacation last week.
> If I understood well, This part of code decreases mem_cost of allocno,
> making them prefer memory, rather than register if possible.
> This behavior achieves same effect as register re-materialization, right?
In some way.  Reusage of stack slots and re-materialization is actually 
done in reload, IRA only takes that into account.

> I do observe a case in which 11 pseudo allocnos are put in memory
> due to this check condition. That hurts reload pass and generates bad
> codes. So is it possible to introduce more accurate condition or even
> some heuristic information here?

It is possible but it is hard.  People (analogous code was present in 
old register allocator, in IRA Jeff Law, Bernd Schmidt and me tried to 
modify it several times) paid a lot of attention to this code and tried 
to improve this. Changes usually improved one test on specific target 
and worsened other tests on other targets.

First of all, I think you should try to provide more details for your 
case and a solution for the problem (but just removing the code 
modifying memory cost of equiv memory will not work because it really 
helps in many cases).  May be it is not a problem of IRA at all.  I'll 
try to look at the problem and evaluate your solution.