search for: simplifydemandedbits

Hi All, I have faced a problem with TargetLowering::SimplifyDemandedBits with AND. Here is a example as following: /* C source code */ struct A { unsigned int a; unsigned char c1, c2; bool b1 : 1; bool b2 : 1; bool b3 : 1; }; int main () { struct A x[1]; x[0].b1 = false; int s = 0; s = x[0].b1 ? 1 : 0; <--- Here is problem. if (s...

...fixed a bug there recently; are you using trunk? Perfect! I'm using 2.8 for now (am hoping to roll forward to trunk and stay there in a month or two), and 2.8 only had that check for SIGN_EXTEND_INREG, not SRL or others. The bugfix was in r124587. I'm now seeing a similar problem with SimplifyDemandedBits() on a 4-byte-aligned i8 load. LowerLOAD() emits an aligned LD4 followed by an AND with constant 0xFF. SimplifyDemandedBits() sees this and changes it to a zero-extended LD1. Is this the same situation, where a bugfix was made after 2.8? Any idea where to look? > > -Eli Thanks! -Matt

...ions that do the same thing. 2*x+1 and 2*x|1 produce the same result, so we want to canonicalize one to the other. We've chosen (admittedly somewhat arbitrarily) to use | instead of + for the canonical form, because | is strictly simpler: there is no carry ripple. This means that things like SimplifyDemandedBits and other bit propagation problems are simpler. > The reason I ask is that this kind of transformation makes it harder for later code to analyze it. In general, it's a lot easier to reason about arithmetic operations, when they are not interleaved with bit operations. For example, if we s...

Hi, I've noticed that for a while, the instruction combiner would convert certain arithmetic operations (like + or *) into bit-manipulation operations. Specific example I have in mind is converting "2*x+1" into "(x<<1)|1". What is the intention of doing this? The reason I ask is that this kind of transformation makes it harder for later code to analyze it. In

...; are you using trunk? > > Perfect!  I'm using 2.8 for now (am hoping to roll forward to trunk and stay > there in a month or two), and 2.8 only had that check for SIGN_EXTEND_INREG, > not SRL or others.  The bugfix was in r124587. > > I'm now seeing a similar problem with SimplifyDemandedBits() on a > 4-byte-aligned i8 load.  LowerLOAD() emits an aligned LD4 followed by an AND > with constant 0xFF.  SimplifyDemandedBits() sees this and changes it to a > zero-extended LD1.  Is this the same situation, where a bugfix was made > after 2.8?  Any idea where to look? The followin...

...there are many places that don't respect the Mask. Closer > > reading of the comment leads me to believe the Mask is simply a > > time-saving device, not a correctness-enforcing mechanism. > > That's fine, but if you fix it that way, please audit > InstructionCombiner SimplifyDemandedBits, which I believe has the same bug. Ok. > > I've fixed the PHI analysis to do the min in our code and it fixes the > > testcase I was working on. Doing a min like this would also allow us > > to have PHI nodes compute known zero and one bits even when there > > isn'...

On 10/17/2012 11:57 AM, Chris Lattner wrote: > > We do want one canonical form, but it would be an interesting experiment to see what happens when we turned 'or' into 'add' instead of the other way around. We'd have to make sure that simplifydemandedbits and friend can handle the add case as well as the or case, but I think it is already close to smart enough to do that. I looked in Reassociate.cpp and I saw that it internally converts shifts into multiplications. I think it would be worthwhile to at least investigate this possibility further....

...> > That said, there are many places that don't respect the Mask. Closer > reading of the comment leads me to believe the Mask is simply a > time-saving device, not a correctness-enforcing mechanism. That's fine, but if you fix it that way, please audit InstructionCombiner SimplifyDemandedBits, which I believe has the same bug. > I've fixed the PHI analysis to do the min in our code and it fixes the > testcase I was working on. Doing a min like this would also allow us > to have PHI nodes compute known zero and one bits even when there > isn't a recurrence. Great!...

...ends with rotate support detect this type of pattern at the DAG stage and map it to a rotate instruction. This, in a nutshell, is the argument against a direct rotate in the IR: the existing primitives are sufficient to model it, and doing so allows LLVM to leverage transforms and analyses such as SimplifyDemandedBits that know how to deal with the more common regular shifts to work on bit rotate expressions as well. Adding a new primitive would mean that a whole bunch of optimization passes would need to know how to deal with it (or else they might lose on optimization opportunities). Variable-distance rotates...

Thanks for getting back to me. So those nodes record if the type has already been expanded from a narrower type. Can you elaborate how I could use these to help? Again, I'm pretty unfamiliar with the SDNodes. Thanks. On Tue, Jan 27, 2015 at 3:22 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 01/27/2015 12:16 PM, Ryan Taylor wrote: > > I have a CopyToReg that

...epth. There is no caching of queries which can result in substantial losses in compile time. Introducing a caching layer (probably in the form of an Analysis pass) would be a useful improvement. However, there are significant complications around invalidation of the cached information (e.g. simplifyDemandedBits) which will require careful thought and design. This project would probably be best for a student with some existing experience in the LLVM code base.

On Wed, Jul 27, 2011 at 2:28 PM, Matt Johnson <johnso87 at crhc.illinois.edu> wrote: > Hi All, >     I'm writing a backend for a target which only supports 4-byte, > 4-byte-aligned loads and stores.  I custom-lower all {*EXT}LOAD and > STORE nodes in TargetISelLowering.cpp to take advantage of all alignment > information available to the backend, rather than treat each

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

...detect this type > of pattern at the DAG stage and map it to a rotate instruction. > > This, in a nutshell, is the argument against a direct rotate in the IR: > the existing primitives are sufficient to model it, and doing so allows > LLVM to leverage transforms and analyses such as SimplifyDemandedBits that > know how to deal with the more common regular shifts to work on bit rotate > expressions as well. Adding a new primitive would mean that a whole bunch > of optimization passes would need to know how to deal with it (or else they > might lose on optimization opportunities). > &...

Hi All, I'm writing a backend for a target which only supports 4-byte, 4-byte-aligned loads and stores. I custom-lower all {*EXT}LOAD and STORE nodes in TargetISelLowering.cpp to take advantage of all alignment information available to the backend, rather than treat each load and store conservatively, which takes O(10) instructions. My target's allowsUnalignedMemoryOperations()

...ted depth. There is no caching of queries which can result in substantial losses in compile time. Introducing a caching layer (probably in the form of an Analysis pass) would be a useful improvement. However, there are significant complications around invalidation of the cached information (e.g. simplifyDemandedBits) which will require careful thought and design. This project would probably be best for a student with some existing experience in the LLVM code base. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/c...

...ISD::CondCode CC = cast<CondCodeSDNode>(N0.getOperand(2))->get(); CC = ISD::getSetCCInverse(CC, N0.getOperand(0).getValueType().isInteger()); return DAG.getSetCC(dl, VT, N0.getOperand(0), N0.getOperand(1), CC); } and the AND is then dropped by TargetLowering::SimplifyDemandedBits ... switch (Op.getOpcode()) { ... case ISD::AND: // If the RHS is a constant, check to see if the LHS would be zero without // using the bits from the RHS. Below, we use knowledge about the RHS to // simplify the LHS, here we're using information from the LHS to simp...

You could set the AND operation action to custom. The problem is that you would have no way of knowing if the type 'v4i64' originated from v4i1 or v4i64. And I don't think that you can use SimplifyDemandedBits (to discover if only the high bit is set) during the legalizer because the DAG is in a strange state, but I could be mistaken on this one. Okay, here is another idea. There are several DAGCombine invocations, including one before the type-legalizer. You can define a target-specific DAGCombine...

...n those bits - IR shifts don't mask their shift amounts. I.e we can't replace `x >> (32-y)` with `x >> (-y)`, which would be legal transform should we not demand those bits. We very much demand them. We just know those bits to be zero. And i'm not sure how to convey that to SimplifyDemandedBits(). I can't pass the Known down the stack, the function resets it first thing, so Known can only be passed from callee to the caller. This is why i'm asking whether anyone is concerned if we proceed with https://reviews.llvm.org/D68150 On Tue, Oct 1, 2019 at 10:44 PM Nikita Popov <nikit...

...39;t respect the Mask. >>> Closer >>> reading of the comment leads me to believe the Mask is simply a >>> time-saving device, not a correctness-enforcing mechanism. >> >> That's fine, but if you fix it that way, please audit >> InstructionCombiner SimplifyDemandedBits, which I believe has the >> same bug. > > Ok. > >>> I've fixed the PHI analysis to do the min in our code and it fixes >>> the >>> testcase I was working on. Doing a min like this would also allow >>> us >>> to have PHI nodes co...