On Wed, Apr 25, 2012 at 10:46 PM, Vladimir Makarov <vmaka...@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.
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?
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?
Thanks.
--
Best Regards.
