search for: computemaskedbit

In tracking down an alignment bug, I think I found a problem in ComputeMaskedBits. But I am not very well versed in this area of LLVM and need some more eyes. This is in the 2.3 release, though it looks like the relevant pieces operate the same way in trunk. I have the following add recurrence: %r849 = select i1 %r848, i64 0, i64 %r847 ; <i64> [#uses=10] %r862 =...

I've always found the name ComputeMaskedBits a bit unintuitive, and since r154011 it's even worse because there is no masking going on whatsoever: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120402/140280.html Is there any appetite for a global rename to ComputeKnownBits? Or any other better names? Thanks, Jay.

On 13 May 2014 21:27, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 13 May 2014 14:33, Jay Foad <jay.foad at gmail.com> wrote: >> I've always found the name ComputeMaskedBits a bit unintuitive, and >> since r154011 it's even worse because there is no masking going on >> whatsoever: >> >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120402/140280.html >> >> Is there any appetite for a global rename to ComputeKnown...

On Saturday 19 July 2008 23:53, Nick Lewycky wrote: > > 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

Sorry for being out of touch. Has this been fixed? Evan On Jul 21, 2008, at 1:09 PM, David Greene wrote: > On Saturday 19 July 2008 23:53, Nick Lewycky wrote: > >>> 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

On Wednesday 20 August 2008 18:08, Evan Cheng wrote: > Sorry for being out of touch. Has this been fixed? I've been trying to test it but have had problems due to the llvm-gcc bootstrap problems I mentioned last week. It's had lots of testing over here so I'll just check it in today. -Dave

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

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

...zeInBits(); This should be an unsigned, like the result type of getScalarSizeInBits(). > + APInt mask(width, 0), zeroes(width, 0), ones(width, 0); > + mask.setAllBits(); An easier way to get an all-one mask would be to construct it as 'APInt mask(width, -1, true)'. > + ComputeMaskedBits(LHS, mask, zeroes, ones); > + zeroes.flipAllBits(); > + > + if ((power = ones.exactLogBase2()) != -1 && zeroes == ones) { It would probably be cleaner to assign 'power' outside the condition. I don't think you're handling the case where the only set bit is...

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

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

...n is not done? Maybe if > I choose flags correctly it is done? Yes; instcombine normally handles situations like this, but there's a recursion limit so pathological cases don't blow the stack and/or cause very long running times. In this particular case, I believe the limit is in llvm::ComputeMaskedBits. > 2- Do you think I can use LLVM library in way that this kind of optimization > is performed? For example is it possible that I call passes responsible for > this in a loop and then ask them in each iteration if they did something > useful and then I stop when they say they didn'...

...ackend. > A possibly important difference between the earlier example and the > current unsigned case: > is a select with a zero constant operand easier to reason about in IR > than the canonical min/max? It might be in some cases... maybe? I mean, it might be easier to analyze in ComputeMaskedBits or something, but we don't really do much to optimize selects involving zero. -Eli > On Tue, May 16, 2017 at 5:30 AM, Koval, Julia <julia.koval at intel.com > <mailto:julia.koval at intel.com>> wrote: > > (1.16) > %cmp = icmp ugt i16 %x, %y > %sub2...

...llvm::SDValue, llvm::SDValue, llvm::SDValue, llvm::SDValue, llvm::ISD::CondCode, bool) in libLLVMSelectionDAG.a(DAGCombiner.cpp.o) llvm::FunctionLoweringInfo::set(llvm::Function const&, llvm::MachineFunction&)in libLLVMSelectionDAG.a(FunctionLoweringInfo.cpp.o) llvm::ComputeMaskedBits(llvm::Value*, llvm::APInt const&, llvm::APInt&, llvm::APInt&, llvm::TargetData const*, unsigned int)in libLLVMAnalysis.a(ValueTracking.cpp.o) (anonymous namespace)::SelectionDAGLegalize::EmitStackConvert(llvm::SDValue, llvm::EVT, llvm::EVT, llvm::DebugLoc)...

Hi all, The InstructionCombining pass causes alignment of globals to be ignored. I've attached a replacement of Fibonacci.cpp which reproduces this (I used 2.3 release). Here's the x86 code it produces: 03C20019 movaps xmm0,xmmword ptr ds:[164E799h] 03C20020 mulps xmm0,xmmword ptr ds:[164E79Ah] 03C20027 movaps xmmword ptr ds:[164E799h],xmm0 03C2002E

Hello I compiled the following program using the web interface #include <stdio.h> #include <stdlib.h> int main(int argc, char **argv) { int a; int b; int c; int d; int X = 10; a = 777; b = a | (atoi(argv[1])); c = b | (atoi(argv[2])); a = c | (atoi(argv[4])); b = a | (atoi(argv[5])); d = b | (atoi(argv[6])); a = d | (atoi(argv[7])); b = a | (atoi(argv[8])); c =

...ample, (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 (RippleBucketExists(RHSKnownZero, RHSKnownOne, LHSKnownZero, width)) >...

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>

...g 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 simplify // the RHS. if (ConstantSDNode *RHSC = dyn_cast<ConstantSDNode>(Op.getOperand(1))) { APInt LHSZero, LHSOne; TLO.DAG.ComputeMaskedBits(Op.getOperand(0), NewMask, LHSZero, LHSOne, Depth+1); // If the LHS already has zeros where RHSC does, this and is dead. if ((LHSZero & NewMask) == (~RHSC->getAPIntValue() & NewMask)) return TLO.CombineTo(Op, Op.getOperand(0)); As n...