Re: [PATCH, SMS 2/2] Support instructions with REG_INC_NOTE (second try)

[Revital Eres <revital dot eres at linaro dot org>]

Hello,

> Ok, this does have two anti-dep edges. But still, only a single true
> dependence(?) ... can you see why?

The intra edge [3681 -(T,2,0)-> 3682] was created by haifa-sched and I guess
that because both of the expected true-dep edges (one for the target
and one for the address) are identical only one is created.  The rest
of the inter edges were created in ddg.c where we do not check for
multiply identical edges.

Thanks,
Revital



>
> Thanks,
> Ayal.
>
>
>> Node num: 2
>> (insn 3681 3678 3682 500 (set (reg:QI 2914 [ MEM[base: D.9586_4130,
>> offset: 0B] ])
>> ? ? ? ?(mem:QI (pre_dec:DI (reg:DI 1644 [ ivtmp.687 ])) [0 MEM[base:
>> D.9586_4130, offset: 0B]+0 S1 A8])) ../../gcc/libiberty/regex.c:4259
>> 358 {*movqi_internal}
>> ? ? (expr_list:REG_INC (reg:DI 1644 [ ivtmp.687 ])
>> ? ? ? ?(nil)))
>> OUT ARCS: ?[3681 -(T,2,1)-> 3681] ?[3681 -(T,2,0)-> 3682]
>> IN ARCS: ?[3682 -(A,0,1)-> 3681] ?[3681 -(T,2,1)-> 3681] ?[3682
>> -(A,0,1)-> 3681] ?[3682 -(T,2,1)-> 3681]
>> Node num: 3
>> (insn 3682 3681 3683 500 (set (mem:QI (plus:DI (reg:DI 1644 [ ivtmp.687 ])
>> ? ? ? ? ? ? ? ?(const_int 3 [0x3])) [0 MEM[base: D.9586_4130, offset:
>> 3B]+0 S1 A8])
>> ? ? ? ?(reg:QI 2914 [ MEM[base: D.9586_4130, offset: 0B] ]))
>> ../../gcc/libiberty/regex.c:4259 358 {*movqi_internal}
>> ? ? (expr_list:REG_DEAD (reg:QI 2914 [ MEM[base: D.9586_4130, offset: 0B] ])
>> ? ? ? ?(nil)))
>> OUT ARCS: ?[3682 -(A,0,1)-> 3681] ?[3682 -(A,0,1)-> 3681] ?[3682
>> -(O,0,0)-> 7263] ?[3682 -(A,0,0)-> 3683] ?[3682 -(T,2,1)-> 3681]
>> IN ARCS: ?[3681 -(T,2,0)-> 3682]
>>
>> Another example of usage is as follows (the address register is not
>> used in MEM):
>>
>> Node num: 0
>> (insn 1419 1415 1423 9 (set (mem/f:DI (pre_inc:DI (reg:DI 1882 [
>> ivtmp.1636 ])) [3 MEM[base: D.10911_2945, offset: 0B]+0 S8 A64])
>> ? ? ? ?(reg/f:DI 3923)) ../../gcc/libiberty/regex.c:5788 378
>> {*movdi_internal64}
>> ? ? (expr_list:REG_INC (reg:DI 1882 [ ivtmp.1636 ])
>> ? ? ? ?(nil)))
>> OUT ARCS: ?[1419 -(T,2,1)-> 1419] ?[1419 -(O,0,0)-> 5932] ?[1419
>> -(O,0,0)-> 1449] ?[1419 -(T,2,1)-> 1434] ?[1419 -(T,2,0)-> 1434]
>> [1419 -(T,2,0)-> 1432] ?[1419 -(O,0,0)-> 1431] ?[1419 -(O,0,0)-> 1427]
>> ?[1419 -(O,0,0)-> 1423]
>> IN ARCS: ?[1419 -(T,2,1)-> 1419] ?[1432 -(A,0,1)-> 1419] ?[1449
>> -(O,0,1)-> 1419] ?[1434 -(A,0,1)-> 1419] ?[1431 -(O,0,1)-> 1419]
>> [1427 -(O,0,1)-> 1419] ?[1423 -(O,0,1)-> 1419]
>> Node num: 4
>> (insn 1432 1431 1433 9 (set (reg:DI 2632)
>> ? ? ? ?(plus:DI (reg/v/f:DI 1058 [ reg_info ])
>> ? ? ? ? ? ?(reg:DI 1882 [ ivtmp.1636 ])))
>> ../../gcc/libiberty/regex.c:5543 79 {*adddi3_internal1}
>> ? ? (nil))
>> OUT ARCS: ?[1432 -(A,0,1)-> 1419] ?[1432 -(T,1,0)-> 1433]
>> IN ARCS: ?[1419 -(T,2,0)-> 1432]
>>
>>>> OK for mainline?
>>>>
>>>
>>> OK, with the following comments:
>>
>> Thanks, will address the comments and re-submit.
>>
>>> In other words, one would expect to see two Anti-dep edges from insn 2
>>> to insn 1, right?
>>
>> Yes, that's indeed the case in the first example above.
>>
>> Thanks,
>> Revital
>>
>