[llvm-dev] A question about dag combine2

[Y Song via llvm-dev]

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>