<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 21, 2014 at 6:45 PM, Jiangning Liu <span dir="ltr"><<a href="mailto:liujiangning1@gmail.com" target="_blank">liujiangning1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Dan,<div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2014-09-20 2:54 GMT+08:00 Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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></blockquote><div><br></div></span><div>This might be true. The algorithm originally bails out immediately whenever a value is lowered to be overdefined, and now it will be changed to be searching the predecessor blocks if it is overdefined value. But other values that are lower than overdefined value will never be lowered again.If we use typical data flow algorithm to lower the lattice, the time complexity should be proportional to the depth of loop. So in reality the time complexity is OK. And I don't see big compile-time overhead with my new patch by adding a threshold by controlling the number of basic blocks to be checked.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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><span><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></span><div style="line-height:20px">This does not explain why BB2's value of %v started out as overdefined.</div></div></blockquote><div><br></div></span><div>This is because the lattice will be lowered to be overdefined as soon as it has ever been lowered/encountered once. For this case, when checking the value on edge BB2->BB3, it will be immediately lowered from undefined to overdefined for BB2. And this value can actually be further lowered to be a constant range after checking BB2's predecessors. So the lowering procedure for this value is like,</div><div><br></div><div>undefined -> overdefined -> constant range.</div></div></div></div></div></blockquote><div><br></div><div><br></div><div>This not lowering.</div><div><br></div><div>undefined is one end of the lattice.</div><div>overdefined is the other.</div><div>constant is in the *middle* of the lattice.</div><div><br></div><div>No matter which you call top and which you call bottom, the value has reached the end of the lattice.</div><div>It should never go back to the middle.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> // Otherwise, this is the first time we're seeing this block. Reset the<br></div><div><div> // lattice value to overdefined, so that cycles will terminate and be</div><div> // conservatively correct.</div><div> BBLV.markOverdefined();</div></div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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></blockquote><div><br></div></span><div>This is not the case, and I don't see the wrong propagation order. Because this is a lazy value info calculation, and the customers of this algorithm may invoke it anytime, and at that time it is possible that there isn't any cached value for the value being checked yet. And eventually we have to lower that value from scratch.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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></blockquote><div><br></div></span><div>Yes. Agree.</div></div></div></div></div></blockquote><div><br></div><div>So can you explain how you aren't doing this?<br><br></div><div>It looksl ike you think the lattice goes</div><div>undefined</div><div>overdefined</div><div>constant</div><div><br></div><div>That should 100% not be the case</div><div>the lattice order should be</div><div>undefined</div><div>constant</div><div>overdefined</div><div><br></div><div>undefined means you don't know</div><div>constant means it has one value.</div><div>overdefined means it has too many values<br></div><div><br></div><div>This is a traditional value range lattice (though sometimes there are more things in the middle).</div><div>There is no way you should go from overdefined back to constant.</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="line-height:20px"><br></div></div><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" target="_blank">liujiangning1@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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>
</div></div></blockquote></span></div><br></div></div></div>
</blockquote></div><br></div></div>