On Mon, May 7, 2012 at 10:20 PM, Vladimir Makarov <vmaka...@redhat.com> wrote:
> On 04/26/2012 04:49 AM, Bin.Cheng wrote:
>>
>> 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.
>
> 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.
>
Actually I noticed this code when analyzing code size with "Os" and found
it causes code size regression in several cases. I will try to abstract some
common senses from all the cases I encountered and see if it could be fixed.
I will update you any progress on this. Thanks.
--
Best Regards.
