[LLVMbugs] [Bug 1261] [apint] instcombine miscompilation

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Sat Apr 7 15:05:48 PDT 2007


rspencer at x10sys.com changed:

           What    |Removed                     |Added
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

------- Additional Comments From rspencer at x10sys.com  2007-04-07 17:05 -------
The Demanded Mask makes these transitions:

ret i16 %D                    0xFFFF (all bits demanded in %D)
%D = trunc i32 %C to i16      0x0000FFFF (widen to include trunc'd bits)
%C = lshr i32 %B, 15          0x7FFF8000 (get shifted bits)
%B = add i32 %A, 16384        0x7FFFFFFF (16 bit value added affects low bits)
%A = sext i31 %zzz to i32     0x7FFFFFFF 

Despite my previous comment, this looks correct to me. The high bit is not
included in the shift because the truncation occurs at 16 bits while the shift
was 15 bits. This is reflected in the DemandedMask shown above.  In this
sitaution, InstCombine opts to replace a sext with an equivalent zext because
the high bit is not preserved downstream. The code looks like:

    // If the input sign bit is known zero, or if the NewBits are not demanded
    // convert this into a zero extension.
    if (RHSKnownZero[SrcBitWidth-1] || (NewBits & ~DemandedMask) == NewBits)
      // Convert to ZExt cast
      CastInst *NewCast = new ZExtInst(I->getOperand(0), VTy, I->getName(), I);
      return UpdateValueUsesWith(I, NewCast);

Presumably this is because zext is cheaper than sext on some hardware.

So, I'm claiming that the sext -> zext is correct and appropriate.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

More information about the llvm-bugs mailing list