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

[Vladimir Makarov]

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.