Hey Jiangning,<br><span style="line-height:20px">Note that this also changes it from being O(n) to O(n^2) in terms of number of iterations, since things can go back up the lattice now. It also should never happen :)</span><div><span style="line-height:20px"><br></span><div style="line-height:20px"><br></div><div style="line-height:20px">In the comments, you say</div><div style="line-height:20px"><span style="line-height:19.7999992370605px">+ // Once this BB is encountered, Val's value for this BB will not be Undefined</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ // any longer. When we encounter this BB again, if Val's value is Overdefined,</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ // we need to compute its value again.</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ //</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ // For example, considering this control flow,</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ // BB1->BB2, BB1->BB3, BB2->BB3, BB2->BB4</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ //</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ // Suppose we have "icmp slt %v, 0" in BB1, and "icmp sgt %v, 0" in BB3. At</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ // the very beginning, when analyzing edge BB2->BB3, we don't know %v's value</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ // in BB2, and the data flow algorithm tries to compute BB2's predecessors, so</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ // then we know %v has negative value on edge BB1->BB2. And then we return to</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ // check BB2 again, and at this moment BB2 has Overdefined value for %v in</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ // BB2. So we should have to follow data flow propagation algorithm to get the</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ // value on edge BB1->BB2 propagated to BB2, and finally %v on BB2 has a</span><br style="line-height:19.7999992370605px"><span style="line-height:19.7999992370605px">+ // constant range describing a negative value.</span><br></div><div style="line-height:20px"><br></div><div style="line-height:20px">This does not explain why BB2's value of %v started out as overdefined.</div><div style="line-height:20px">Somewhere in here, either propagation order is wrong, or the CFG has some weirdness (is the CFG above the complete description of the testcase? Are there critical edges).</div><div style="line-height:20px"><br></div><div style="line-height:20px">IMHO, You should never have a case where things to go the wrong direction in the lattice.</div><div style="line-height:20px"><br></div></div><br><div class="gmail_quote">On Thu Sep 11 2014 at 8:47:56 PM Jiangning Liu <<a href="mailto:liujiangning1@gmail.com">liujiangning1@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Joerg,<div><br></div><div>Thanks for your command line, and it works!</div><div><br></div><div>I've sent out a patch email to fix this problem, and you may want to have a look.</div><div><br></div><div>Sorry for any inconvenience caused!</div><div><br></div><div>Thanks again,</div><div>-Jiangning</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-09-09 17:50 GMT+08:00 Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, Sep 09, 2014 at 11:41:00AM +0800, Jiangning Liu wrote:<br>
> Hi Joerg,<br>
><br>
> Sorry to know about this... I just came back from mid-autumn holiday...<br>
><br>
> Can you tell me how you measured the memory consumption for llvm?<br>
<br>
</span>Build with /usr/bin/time -v clang -O2 -c.<br>
<div><div><br>
Joerg<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</blockquote></div>