[InstCombine] don't use DeMorgan's Law on integer constants
authorSanjay Patel <spatel@rotateright.com>
Tue, 2 May 2017 14:31:30 +0000 (14:31 +0000)
committerSanjay Patel <spatel@rotateright.com>
Tue, 2 May 2017 14:31:30 +0000 (14:31 +0000)
commit096a98198241c51822d246e3687831fff31700c7
tree0dfe76c3df034af9ebe5796b32882d922775b098
parent106a7eab8494b6cd027eaad2b9dacd5dcc62a5af
[InstCombine] don't use DeMorgan's Law on integer constants

This is the fold that causes the infinite loop in BoringSSL
(https://github.com/google/boringssl/blob/master/crypto/cipher/e_rc2.c)
when we fix instcombine demanded bits to prefer 'not' ops as in D32255.

There are 2 or 3 problems with dyn_castNotVal, and I don't think we can
reinstate D32255 until dyn_castNotVal is completely eliminated.
1. As shown here, it transforms 'not' into random xor. This transform is
   harmful to SCEV and codegen because 'not' can often be folded while
   random xor cannot.
2. It does not transform vector constants. This is actually a good thing,
   but if you don't believe the above argument, then we shouldn't have
   excluded vectors.
3. It tries to avoid transforming not(not(X)). That's nice, but it doesn't
   match the greedy nature of instcombine. If we DeMorganize a pattern
   that has an extra 'not' in it:
   ~(~(~X) & Y) --> (~X | ~Y)

   That's just another case of DeMorgan, so we should trust that we'll fold
   that pattern too:
   (~X | ~ Y) --> ~(X & Y)

Differential Revision: https://reviews.llvm.org/D32665

llvm-svn: 301923
llvm/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp
llvm/test/Transforms/InstCombine/assume2.ll
llvm/test/Transforms/InstCombine/demorgan.ll