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.
