search for: knownzero

I'm trying to reason about how to find certain bit positions of the absolute value of a given integer value. Specifically, I want to know the highest possibly set bit and lowest possibly set bit of the absolute value, in order to find the range between the two. Note that I'm specifically trying to be as conservative as possible. This is what I have so far: If the sign bit of the

...Phabricator.) +1 In your example, we have: 3 - idx == idx => 3 == 2*idx and you've generalized this slightly to make this: (odd number) == 2*idx which makes sense. I think that we can go further looking at: n == 2*idx and, calling computeKnownBits on n and idx, then asking whether: knownZeros(n) == (knownZeros(idx) << 1) | 1 and knownOnes(n) == knownOnes(idx) << 1 (please note the comment in aliasSameBasePointerGEPs regarding avoiding PR32314) also, if we have more than one array access, we can have: n - idx == m - idx then we have: n-m == 2*idx and so we can check:...

...or those instructions. So the recurrence looks like: SR_S112.0 = phi(r849 << 3, sh r849 << 6 + SR_S112.0) ComputeMaskedBits correctly identifies the recurrence and sets L = %r851 = shl i64 %r849, 6 ; <i64> [#uses=16] R = %r862 = shl i64 %r849, 3 ComputeMaskedBits on R returns KnownZero as 0x7, as expected. The PHI-analysis code in ComputeMaskedBits sets Mask2 to 0x7. It then calls itself recursively on L passing Mask2 as the mask. Here's where the problem creeps in. ComputeMaskedBits returns KnownZero as 0x3f for L. Shouldn't the passed Mask limit it to returning 0...

...lysis/ValueTracking.cpp (revision 125281) +++ lib/Analysis/ValueTracking.cpp (working copy) @@ -593,6 +593,8 @@ // Otherwise take the unions of the known bit sets of the operands, // taking conservative care to avoid excessive recursion. if (Depth < MaxDepth - 1 && !KnownZero && !KnownOne) { + if (!P->getNumIncomingValues()) + return; KnownZero = APInt::getAllOnesValue(BitWidth); KnownOne = APInt::getAllOnesValue(BitWidth); for (unsigned i = 0, e = P->getNumIncomingValues(); i != e; ++i) { -- Jakub Staszak

...tch 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...

On Friday 18 July 2008 00:36, Nick Lewycky wrote: > David Greene wrote: > > Is my analysis correct? If so, is the PHI code the culprit (for not > > returning the min of the KnownZero bits) or is the Shl code the culprit > > (for not paying attention to the Mask passed in (it right shifts it)? > > I think your analysis is correct, and that Shl -- and many of the other > operations (AShr, LShr, SExt, Add?, Call?) -- should be modified to > always respect Mask....

Hello All, I have met one may-alias case from llvm's alias analysis. The code snippet is as following: char buf[4]; void test (int idx) { char *a = &buf[3 - idx]; char *b = &buf[idx]; *a = 1; *b = 2; } I can see below output from alias set tracker for above code snippet. Alias sets for function 'test': Alias Set Tracker: 1 alias sets for 2 pointer values.  

David Greene wrote: > Is my analysis correct? If so, is the PHI code the culprit (for not returning > the min of the KnownZero bits) or is the Shl code the culprit (for not paying > attention to the Mask passed in (it right shifts it)? I think your analysis is correct, and that Shl -- and many of the other operations (AShr, LShr, SExt, Add?, Call?) -- should be modified to always respect Mask. Nick

...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...

...alignment on the store? It emits a store without alignment information, and instcombine adds the explicit alignment according to the langref (pref alignment). 2) If we know that the store is aligned, shouldn't instcombine deduce that the pointer %bar itself must be aligned (set low bits in KnownZero), and use this information for other uses, at least those that are dominated by the store? This would fold the three instructions to "ret i64 0". 3) If instcombine cannot deduce it, is there a way to annotate that a specific pointer value is aligned? In my case it should work to add t...

...p;r1=132162&r2=132163&view=diff > ============================================================================== > --- llvm/trunk/lib/Analysis/ValueTracking.cpp (original) > +++ llvm/trunk/lib/Analysis/ValueTracking.cpp Thu May 26 18:13:19 2011 > @@ -680,8 +680,8 @@ > KnownZero = APInt::getHighBitsSet(BitWidth, BitWidth - LowBits); > break; > } > - case Intrinsic::x86_sse42_crc64_8: > - case Intrinsic::x86_sse42_crc64_64: > + case Intrinsic::x86_sse42_crc32_64_8: > + case Intrinsic::x86_sse42_crc32_64_64: > Kn...

...e explicit alignment according to > the langref (pref alignment). Without an explicit alignment means the ABI alignment in the case of loads/stores. > 2) If we know that the store is aligned, shouldn't instcombine deduce that the > pointer %bar itself must be aligned (set low bits in KnownZero), and use this > information for other uses, at least those that are dominated by the store? This > would fold the three instructions to "ret i64 0". Probably it should. Doing so would require that LLVM semantics considers an unaligned load/store to result in undefined behaviour,...

...ds/stores. Yes, that second step was clear. Assuming you meant the "preferential alignment", according to the langref. > >> 2) If we know that the store is aligned, shouldn't instcombine deduce >> that the >> pointer %bar itself must be aligned (set low bits in KnownZero), and >> use this >> information for other uses, at least those that are dominated by the >> store? This >> would fold the three instructions to "ret i64 0". > > Probably it should. Doing so would require that LLVM semantics > considers an > unaligned...

Can someone explain what this function is supposed to do? I've looked at PowerPC, Sparc, etc.. and can't really figure out what I should be doing here. Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part

David Greene wrote: > On Friday 18 July 2008 00:36, Nick Lewycky wrote: >> David Greene wrote: >>> Is my analysis correct? If so, is the PHI code the culprit (for not >>> returning the min of the KnownZero bits) or is the Shl code the culprit >>> (for not paying attention to the Mask passed in (it right shifts it)? >> I think your analysis is correct, and that Shl -- and many of the other >> operations (AShr, LShr, SExt, Add?, Call?) -- should be modified to >> always respe...

...ed 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);...

...ABI alignment. If the LangRef says the preferential alignment then I'm pretty sure the LangRef is wrong! > >> >>> 2) If we know that the store is aligned, shouldn't instcombine deduce >>> that the >>> pointer %bar itself must be aligned (set low bits in KnownZero), and >>> use this >>> information for other uses, at least those that are dominated by the >>> store? This >>> would fold the three instructions to "ret i64 0". >> >> Probably it should. Doing so would require that LLVM semantics >>...

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 Andrew, Thank you for the suggestion. I've looked at CodeGenPrepare.cpp and MoveExtToFormExtLoad() is never run. I also notice that the ARM target produces the same additional register usage (copy) and zero extending (of the copy). (See the usage of r3 &r5 and also r12 & r4 in attached file arm-strcspn.s, my understanding is that 'ldrb' is zero extending.) Here is a

On Sep 10, 2013, at 8:59 AM, Robert Lytton <robert at xmos.com> wrote: > Hi, > > A bit more information. > I believe my problem lies with the fact that the load is left as 'anyext from i8'. > On the XCore target we know this will become an 8bit zext load - as there is no 8bit sign extended load! > If BB#1 were to force the load to a "zext from i8" would