[llvm-dev] undef * 0

sohachak via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 14 04:55:26 PDT 2016


Hi,

 > Both A and B are undef:
 >    LHS = (undef & undef) | (undef & undef) = undef // Since ~undef = 
undef
 >    RHS = undef
 >    Thus transform is correct.

LLVM documentation (http://llvm.org/docs/LangRef.html#undefined-values) 
suggests that

it is unsafe to consider (a & undef = undef) and  (a | undef = undef).

"As such, it is unsafe to optimize or assume that the result of the 
‘|and|‘ is ‘|undef|‘. However, it is safe to assume that all bits of the 
‘|undef|‘ could be 0, and optimize the ‘|and|‘ to 0. Likewise, it is 
safe to assume that all the bits of the ‘|undef|‘ operand to the ‘|or|‘ 
could be set, allowing the ‘|or|‘ to be folded to -1."


As a result,
    LHS = (undef & undef) | (undef & undef) = c_1 | c_2 where c_1 and 
c_2 are constants and as a result,

  And finally,  LHS = c where c is a constant; not undef.


Please correct me if I am missing something.

Best Regards,

soham


On 9/13/2016 7:27 PM, Sanjoy Das wrote:
> Hi Soham,
>
> Soham Chakraborty wrote:
> > As a result,  the transformation ' ((a&  (~b)) |((~a)&  b)) ~>  xor 
> a b '
> > is unsound. LLVM presently performs this transformation.
>
> This transform looks fine to me.
>
> For simplicity let's look at an `i1` expression.  Since these are
> bitwise ops we can extend the reasoning below to iN.
>
> Transform: ((A & (~B)) | ((~A) & B))  ~> A ^ B
>
> Neither A nor B are undef:
>   Transform is correct by normal boolean algebra
>
> Both A and B are undef:
>   LHS = (undef & undef) | (undef & undef) = undef  // Since ~undef = 
> undef
>   RHS = undef
>   Thus transform is correct.
>
> A is undef but B is not undef:
>   LHS = ((undef & (~B)) | (undef & B)) // Since ~undef = undef
>
>   Now, by choosing 0 for undef in LHS, we can make LHS be equal to 0,
>   and by choosing 1 for undef in LHS, we can make LHS be equal to 1.
>   Therefore
>
>   LHS = undef
>   RHS = undef ^ B = undef
>
>   Thus the transform is correct.
>
> A is not undef but B is undef:
>   Similar reasoning follows.
>
> -- Sanjoy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160914/2f61b9d5/attachment.html>


More information about the llvm-dev mailing list