<div dir="ltr">We used to have a serious problem with isSafeToSpeculativelyExecute utilizing computeKnownBits with division.  It'd try to prove the denominator is non-zero to avoid division by zero but get tricked when it was faced with a denominator whose value is produced by a lshr exact and reason that the range of the operation must be constrained within some bound.  However, the lshr could produce any value because it could have been fed in undef or poison for either/both operands thus rendering the constraint in computeKnownBits useless.  I fixed this not too long ago...<div><br></div><div>The only remaining "interesting" use is SimplifyDemandedUseBits.  It is not far-fetched that we would remove an 'or' because we'd think it would be redundant due to computeKnownBits reasoning that undefined behavior would result otherwise.  However, the bit in question might actually be undef with the 'or' being the only remaining operation keeping an undef value from being replaced with zero.</div><div><br></div><div><br></div>







<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 8, 2015 at 10:26 AM, John Regehr via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On the subject of undefined behavior and known bits, as I'm sure some of you are aware, code in ValueTracking.cpp is exploiting poison value rules to get a bit of extra precision in the known bits. These rules fire on examples like the ones below.  Do we have a set of rules that clients of known bits need to follow to avoid unsoundness?  I remember Nuno and/or David Majnemer saying something about this but I don't have it handy.<br>
<br>
John<br>
<br>
<br>
%0:i32 = var<br>
%1:i32 = lshr %0, 1:i32<br>
%2:i32 = addnw 1:i32, %1<br>
infer %2<br>
<br>
known from Souper:   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br>
known from compiler: 0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br>
llvm is stronger<br>
<br>
<br>
<br>
%0:i32 = var (000000000000000xxxxxxxxxxxxxxxxx)<br>
%1:i32 = and 65535:i32, %0<br>
%2:i16 = var<br>
%3:i32 = zext %2<br>
%4:i32 = mulnw %1, %3<br>
infer %4<br>
<br>
known from Souper:   xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br>
known from compiler: 0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br>
llvm is stronger<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div></div>