search for: simplifydemandedusebits

SimplifyDemandedUseBits in part because of the following comment: // FIXME: for XOR, we prefer to force bits to 1 if they will make a -1. will transform %neg = xor i32 %V, -1 %and = and i32 %not, 4096 into %and = and i32 %V, 4096 %xor = xor i32 %and, 4096 which would generate worse code for platforms that have a neg...

...nsics are properties of the targets and don’t leach out, however today they do in a lot of places. What are the specific problems here? Anything that does an equality comparison with the IntrinsicID can be changed to do strcmp with the name. That would handle the one-off cases like InstCombiner::SimplifyDemandedUseBits in InstCombine. The other cases in InstCombine could be handled similarly, but may be better handled by adding a intrinsic behavior query APIs to the intrinsic registry, or would be better handled (eventually) by adding new attributes to the intrinsics themselves. -Chris -------------- next part...

Hi all, Hi Eli, No, that appears to be something unrelated. I'm currently using revision 75246, while that 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(...

...ing unrelated. I'm currently using revision > 75246, while that patch only seems to apply to some later revision. I don't see the connection... anyway, I can't easily help you 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<Pointe...

On the subject of undefined behavior and known bits, as I'm sure some of you are aware, code in ValueTracking.cpp is exploiting poison value rules to get a bit of extra precision in the known bits. These rules fire on examples like the ones below. Do we have a set of rules that clients of known bits need to follow to avoid unsoundness? I remember Nuno and/or David Majnemer saying

...-------------------------------------------------------------------- For the snippet: %and.i = and i32 %conv.i, 255 ... %r2 = and i32 %and.i, 31 Look at %r2 in block %if.else, it is computed by two "and" operations. Both InstCombiner::SimplifyAssociativeOrCommutative and InstCombiner::SimplifyDemandedUseBits can replace %r2 = and i32 %and.i, 31 with %r2 = and i32 %conv.i, 31. Because %and.i has many other uses and it won't become dead after the simplifications, those simplifications won't simplify instruction cost, but they will change the live range of variables: Before instcombine, %conv.i is...

...es of the targets and don’t leach out, however today they do in a lot of places. >> >> What are the specific problems here? Anything that does an equality comparison with the IntrinsicID can be changed to do strcmp with the name. That would handle the one-off cases like InstCombiner::SimplifyDemandedUseBits in InstCombine. >> >> The other cases in InstCombine could be handled similarly, but may be better handled by adding a intrinsic behavior query APIs to the intrinsic registry, or would be better handled (eventually) by adding new attributes to the intrinsics themselves. > > I do...

On Wed, Jul 29, 2009 at 3:45 AM, Nicolas Capens<nicolas at capens.net> wrote: > So could anyone who knows the ins and outs of this code have a look at how > to make it handle vectors correctly? Or if that’s not an option right now, > please revert the broken optimizations. Note that there might be more things > affected than visitAnd, visitOr and vistXor, I’ve only been able to

...>> For the snippet: >> %and.i = and i32 %conv.i, 255 >> ... >> %r2 = and i32 %and.i, 31 >> >> Look at %r2 in block %if.else, it is computed by two "and" operations. >> Both InstCombiner::SimplifyAssociativeOrCommutative and >> InstCombiner::SimplifyDemandedUseBits can replace %r2 = and i32 >> %and.i, 31 with %r2 = and i32 %conv.i, 31. Because %and.i has many >> other uses and it won't become dead after the simplifications, those >> simplifications won't simplify instruction cost, but they will change >> the live range of varia...

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

Hi Sanjay, > Am 02.08.2016 um 21:39 schrieb Sanjay Patel <spatel at rotateright.com>: > > Hi Matthias - > > Sorry for the delayed reply. I think you're on the right path with D22864. No problem, thank you for your answer! > If I'm understanding it correctly, my foo() example and zext_or_icmp_icmp() will be equivalent after your patch is added to InstCombine.

> On Dec 23, 2014, at 9:45 AM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 22, 2014, at 2:56 PM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >> Circling back to Chandler on file size differences. Here are the highlights of what is different. >> >> For my analysis I built LLVM and Clang using a clang built with my

...--------------------------- > > For the snippet: > %and.i = and i32 %conv.i, 255 > ... > %r2 = and i32 %and.i, 31 > > Look at %r2 in block %if.else, it is computed by two "and" operations. > Both InstCombiner::SimplifyAssociativeOrCommutative and > InstCombiner::SimplifyDemandedUseBits can replace %r2 = and i32 > %and.i, 31 with %r2 = and i32 %conv.i, 31. Because %and.i has many > other uses and it won't become dead after the simplifications, those > simplifications won't simplify instruction cost, but they will change > the live range of variables: > Befor...