Paolo Bonzini schrieb:
> On 10/25/2010 11:35 AM, Georg Lay wrote:
>>>> (insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
>>>> (and:SI (reg:SI 4 d4 [ x ])
>>>> (const_int -98305 [0xfffe7fff]))) 143
>>>> {*and3_zeroes.insert.{SI}.ic}
>>>> (nil))
>>>>
>>>> (insn 23 22 21 2 peep2.c:5 (set (reg:SI 15 d15)
>>>> (xor:SI (reg:SI 15 d15)
>>>> (reg:SI 4 d4 [ x ]))) 39 {*xorsi3} (nil))
>>>>
>>>> (insn 21 23 10 2 peep2.c:5 (set (reg:SI 4 d4)
>>>> (reg:SI 15 d15)) 2 {*movsi_insn} (nil))
>>>>
>>>> (call_insn/j 10 21 11 2 peep2.c:5 (parallel [
>>>> (set (reg:SI 2 d2)
>>>> (call (mem:HI (symbol_ref:SI ("f") [flags
>>>> 0x41]<function_decl
>>>> 0xb76b3280 f>) [0 S2 A16])
>>>> (const_int 0 [0x0])))
>>>> (use (const_int 1 [0x1]))
>>>> ]) 92 {call_value_insn} (nil)
>>>> (expr_list:REG_DEP_TRUE (use (reg:SI 4 d4))
>>>> (nil)))
>>>> ;; End of basic block 2 -> ( 1)
>>>> ;; lr out 2 [d2] 26 [SP] 27 [a11]
>>>> ;; live out 2 [d2] 26 [SP] 27 [a11]
>>>> ;; Succ edge EXIT [100.0%] (ab,sibcall)
>>>>
>>>> (barrier 11 10 20)
>>>>
>>>> D15, is not marked as dead
>>>
>>> True. It should have had a REG_DEAD note. Are you using 4.6 (which
>>> scans forwards in peephole2 and requires REG_DEAD notes) or 4.5 (which
>>> scans backwards)? If the latter, the absence of the note could be a
>>> red
>>> herring, because 4.5 didn't need REG_DEAD notes so it didn't compute
>>> them.
>>
>> It is a target port of 4.5.1. I just skimmed peep2_reg_dead_p and it
>> looks
>> backward.
>
> In this case, as I mentioned the function _doesn't need_ a note to see
> that D15 dies. There's no such thing as a register that is "naturally
> dead because the function ends" and needs special treatment. Liveness
> is computed like everything else from data flow and, when scanning
> backwards, can be computed simply from the defs and uses of each
> instruction. The notes are not necessary, so their absence is (as I
> also have mentioned above already) a red herring.
>
> The definition of liveness is lr_before = lr_after - def + use, which
> gives:
>
> at the end of basic block lr from dump file = {2,26,27}
> insn 10 def = {2}, use = {4} lr before insn 10 = {4,26,27}
> insn 21 def = {4}, use = {15} lr before insn 21 = {15,26,27}
> insn 23 def = {15}, use = {4,15} lr before insn 23 = {4,15,26,27}
> insn 22 def = {15}, use = {4} lr before insn 22 = {4,26,27}
>
> When GCC matches the peephole against 21+23, peep2_reg_dead_p(2, reg)
> should test reg against "lr before insn 10". This is {4,26,27}. You
> have to set a breakpoint in df_simulate_one_insn_backwards and see which
> part of my theory above is incorrect.
Hi, thanks for your detailed answer!
I set a break at the end of df_simulate_one_insn_backwards.
CURRENT = *(live->current->bits)
FIRST = *(live->first->bits)
reg 26 (Stackpointer) and reg 27 (return address) do not matter here.
The result ist
insn 10 (CALL) CURRENT = FIRST = 0xc008010 = {...,4,15}
insn 21 (SET) CURRENT = FIRST = 0xc008000 = {...,15}
insn 23 (XOR) CURRENT = FIRST = 0xc008010 = {...,4,15}
insn 22 (AND) CURRENT = FIRST = 0xc000010 = {...,4}
So 15 is still alive at the call insn.
Whatever the rationale behind all of that is, I don't intend to hack
rtl-optimizers, I'm just a backend guy that strives to use the compiler.
(and I must admit that my ambitions to contribute to GCC never lead to anything.
Even after several requests the FSF didn't sent me a copyright assignment. But
that's OT here).
peep2_reg_dead_p seems to be the only interface that provides some liveness
information to backend developers and so I'm stuck and think it's best to let
this peephole rest in peace...
Georg Lay
