<div dir="ltr">On Tue, Jul 2, 2013 at 4:10 AM, Duncan Sands <span dir="ltr"><<a href="mailto:duncan.sands@gmail.com" target="_blank">duncan.sands@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">


<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">Hi Ahmed,</blockquote><div> </div><div>Hi Duncan! </div><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>
On 02/07/13 06:45, Ahmed Bougacha 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">
Hi all,<br>
<br>
LazyValueInfo seems overly conservative by not even looking at a value it set to<br>
overdefined, solved its LHS, and then came back to.<br>
</blockquote>
<br></div>
please don't forget to include the testcases that show that, with your patch,<br>
LVI gets lots of things it didn't get before. </blockquote><div><br></div><div>See attached testcase. Basically any case where there are binops in the chain of computations will fail to be evaluated.</div><div>Here the testcase is somewhat convoluted because it has to go through CVP, but it really shines when using getConstantRange of that other patch.</div>


<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">Also, did you measure to see what<br>
the compile time impact is?<br></blockquote><div><br></div><div>I’ll try to get some results later.</div><div><br></div><div>-- Ahmed<br></div><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">



Ciao, Duncan.<br>
<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>
<br>
The oneliner lvi-solve-overdef.diff makes it look at overdefined values again.<br>
It seems broken though, especially with the comment a few lines down saying that<br>
it sets it to overdefined "so that cycles will terminate and be conservatively<br>
correct.”<br>
<br>
 From what I read though, if a value is a binop, LVI will look at the LHS,<br>
figure out its lattice value, and then tell you that the binop is overdefined,<br>
even though at this point all the needed information is there.<br>
<br>
In my (limited) testing, this helps, and doesn’t seem to break anything.<br>
Insights welcome!<br>
<br>
<br>
The other patch exposes the constant range when available, which, even though<br>
limited, can be very useful.<br>
<br>
Thanks,<br>
<br>
-- Ahmed Bougacha<br>
<br>
<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>
<br>
</blockquote>
<br>
______________________________<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><br></div></div>