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](align=2), 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](align=2), 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151008/0fc37a5f/attachment-0001.html>