Hi,
Recently, I investigated one BPF bug where a infinite looping happens
dag combine2. The test case, the bug fix and some description of the issue can be
found with the commit:
http://reviews.llvm.org/rL249718
The investigation of the bug does raise some interesting question about
the algorithm of dag combine2 and the usage of UNDEF sdnode, which
I want to get some feedback from the group.
The issue can be described by the following steps:
…
(1). The following node in the worklist is processed:
ch = store<ST2[%7+18], trunc to i16> 0x229b5a0, Constant:i64<0>, 0x2294fb8, Constant:i64<0>
(before legalizer the last operand is undef and BPF Undef expansion legalizes it to
Constant:i64<0>)
(2). The following call sequence
DAGCombiner::visitSTORE
DAG.getTruncStore
VT != SVT (i64, i16)
a new StoreSDNode with ops {Chain, Val, Ptr, Undef} is created
CombineTo
The new StoreSDNode is added to worklist
[!!! I am not sure when Undef node is added to the worklist, but
could be here]
(3). The following node in the worklist is processed:
ch = store<ST2%7(align=8)+18, trunc to i16> 0x229b5a0, Constant:i64<0>, 0x2294fb8, undef:i64
Its StoreSDNode->getAlignment is refined to 2, and node is not added back
to the work list
(4). The following node in the worklist is processed:
i64 = undef
Legalizer actually is able to legalize it to be “i64 = Constant<0>”, and
put both of them as updated nodes. So both of them and their users are
added to the worklist. One of its uses is:
store<ST2%7(align=8)+18, trunc to i16> 0x229b5a0, Constant:i64<0>, 0x2294fb8, Constant:i64<0>
Now we go back to (1) and the whole sequence starts again.
Any potential hole in dag combine2 algorithm esp. related with promoting Undef node?
Thanks,
Yonghong