search for: rhsknownzero

...ctions like add. Just delete this line. > + APInt mask(width, 0), zeroes(width, 0), ones(width, 0); These shadow (have the same name as) the ones before. It's better to reuse the mask and rename the other two. The earlier ones should be LHSKnownZero and LHSKnownOne and these should be RHSKnownZero and RHSKnownOne. This is more consistent with the way they're named elsewhere in LLVM. > + mask.clearAllBits(); This is redundant here because it's already been initialized to zero in the constructor. If you'd reuse the old mask variable as suggested above you'd need this,...

Hi all! I've been tinkering with LLVM's code-base for a few days, hoping to start on one of the ideas mentioned in the "Open Projects" page (I was told 'Improving the current system'/'Miscellaneous Improvements'/5 would be a good start). While I was at it, I also took a stab at finishing up one of the TODOs. I've attached the patch for review. --

Hi As I understand live variable analysis will set the def/kill properties of operands. In that case, is it still needed to set the kill flags when possible during lowering? thanks dz

...ll the zero, but won't change the > // sign. For example, (X & ~4) + 1. > - > - // TODO: Implement. > - > + > + unsigned width = LHS->getType()->getScalarSizeInBits(); > + APInt mask(width, -1, true), LHSKnownZero(width, 0), LHSKnownOne(width, 0), > + RHSKnownZero(width, 0), RHSKnownOne(width, 0); > + > + ComputeMaskedBits(LHS, mask, LHSKnownZero, LHSKnownOne); > + ComputeMaskedBits(RHS, mask, RHSKnownZero, RHSKnownOne); > + > + if (RippleBucketExists(LHSKnownZero, LHSKnownOne, RHSKnownZero, width)) > + return true; > + if (Ripple...

Hi! I've attached a patch which takes care of the issues mentioned (and adds two tests). -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: ripple-bucket.diff Type: text/x-diff Size: 3318 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110308/0814e3e8/attachment.diff>

...ached help? -Eli -------------- next part -------------- Index: InstructionCombining.cpp =================================================================== --- InstructionCombining.cpp (revision 77486) +++ InstructionCombining.cpp (working copy) @@ -1014,7 +1014,7 @@ if ((DemandedMask & (RHSKnownZero|RHSKnownOne)) == DemandedMask) { // all known if ((RHSKnownOne & LHSKnownOne) == RHSKnownOne) { - Constant *AndC = ConstantInt::get(*Context, + Constant *AndC = ConstantInt::get(VTy, ~RHSKnownOne & DemandedMask);...

...patch only seems to apply to some later revision. Anyway, I actually located the real bug. Right at the end of InstCombiner::SimplifyDemandedUseBits, there's this piece of code: // If the client is only demanding bits that we know, return the known // constant. if ((DemandedMask & (RHSKnownZero|RHSKnownOne)) == DemandedMask) { Constant *C = Context->getConstantInt(RHSKnownOne); if (isa<PointerType>(V->getType())) C = Context->getConstantExprIntToPtr(C, V->getType()); return C; } return false; } Note that C is a scalar integer, and so when V is actu...

Hi All, I found a regression which triggers the asserts: "Binary operator types must match!" and "Op types should be identical!". It's happening with a piece of vector code, and the asserts happen because a logic operation is attempted between a vector and a scalar (which is not present in the original code, but created by InstCombine). It's caused by revision

...ou with an old revision. > Anyway, I actually located the real bug. Right at the end of > InstCombiner::SimplifyDemandedUseBits, there's this piece of code: > >  // If the client is only demanding bits that we know, return the known >  // constant. >  if ((DemandedMask & (RHSKnownZero|RHSKnownOne)) == DemandedMask) { >    Constant *C = Context->getConstantInt(RHSKnownOne); >    if (isa<PointerType>(V->getType())) >      C = Context->getConstantExprIntToPtr(C, V->getType()); >    return C; >  } >  return false; > } > > Note that C is a...