Subzero: Don't "and" i1 values with 1.

src/IceTargetLoweringX86BaseImpl.h

Index: src/IceTargetLoweringX86BaseImpl.h
diff --git a/src/IceTargetLoweringX86BaseImpl.h b/src/IceTargetLoweringX86BaseImpl.h
index 16f2b2fc3e62e24f6ff683b6bfc8bbf389b670d9..0b3a32f87c0b0c283d946e971b4f73fc0ebca0cc 100644
--- a/src/IceTargetLoweringX86BaseImpl.h
+++ b/src/IceTargetLoweringX86BaseImpl.h
@@ -2047,15 +2047,10 @@ void TargetX86Base<Machine>::lowerCast(const InstCast *Inst) {
       } else {
         _movzx(Tmp, Src0RM);
       }
-      if (Src0RM->getType() == IceType_i1) {

[John, 2015/10/09 12:14:08]

are you 100% sure this is OK? I've wondered about this for a long time, but
given that llc does something similar, I stopped thinking about it.

[Jim Stichnoth, 2015/10/09 13:50:22]

I'm about 99.44% sure...

The idea is to look through all operations that produce an i1 result and verify
that they all produce an 8-bit 0 or 1 (assuming any i1 inputs are also 0 or 1). 
For i1 arithmetic instructions, only add/or/xor are allowed, which is fine. 
Load is not allowed.  The trunc to i1 instruction still does "and 1".  So do
fptoui and fptosi.  Icmp and fcmp both do set<cc> instructions which result in 0
or 1.  So I think we're OK.

FWIW, the cross tests and spec2k are OK with this, which is what elevates my
confidence from 99% to 99.44%.

-        Constant *One = Ctx->getConstantInt32(1);
-        _and(Tmp, One);
-      }
       _mov(DestLo, Tmp);
       _mov(DestHi, Zero);
     } else if (Src0RM->getType() == IceType_i1) {
-      // t = Src0RM; t &= 1; Dest = t
-      Constant *One = Ctx->getConstantInt32(1);
+      // t = Src0RM; Dest = t
       Type DestTy = Dest->getType();
       Variable *T = nullptr;
       if (DestTy == IceType_i8) {
@@ -2069,7 +2064,6 @@ void TargetX86Base<Machine>::lowerCast(const InstCast *Inst) {
         T = makeReg(DestTy == IceType_i64 ? IceType_i64 : IceType_i32);
         _movzx(T, Src0RM);
       }
-      _and(T, One);
       _mov(Dest, T);
     } else {
       // t1 = movzx src; dst = t1