similar to: [LLVMdev] ComputeMaskedBits Bug

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

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

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

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

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

On Sun, Mar 6, 2011 at 10:11 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > While I was at it, I also took a stab at finishing up one of the TODOs. I've > attached the patch for review. Comments inline. For those of you following at home, this code is in InstCombiner::WillNotOverflowSignedAdd(), and the first line of the initial comment is: // If one of the

Hello, This simple patch fixes PR9112: Index: lib/Analysis/ValueTracking.cpp =================================================================== --- lib/Analysis/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

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

On Tue, Mar 8, 2011 at 6:19 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi! > > I've attached a patch which takes care of the issues mentioned (and adds two > tests). > Index: test/Transforms/InstCombine/sext.ll > =================================================================== > --- test/Transforms/InstCombine/sext.ll (revision 127153) > +++

FYI, The CRC64 intrinsics were renamed to CRC32 since there is no such thing. See below for details. Chad On May 26, 2011, at 4:13 PM, Chad Rosier wrote: > Author: mcrosier > Date: Thu May 26 18:13:19 2011 > New Revision: 132163 > > URL: http://llvm.org/viewvc/llvm-project?rev=132163&view=rev > Log: > Renamed llvm.x86.sse42.crc32 intrinsics; crc64 doesn't exist.

On Thu, Jul 30, 2009 at 5:57 AM, Nicolas Capens<nicolas at capens.net> wrote: > No, that appears to be something 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

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

On Thu, Jun 17, 2010 at 4:30 PM, Ehsan Amiri <ehsanamiri at gmail.com> wrote: > 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 |

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

Hi all, I'm instrumenting IR by replacing loads and stores by calls to a library, which I have compiled to bitcode such that inlining can take place. My problem is: If I could retain the alignment information on the load/store, this would open many optimization opportunities after inlining. Unfortunately, I don't know how. After thinking about it, and trying different things, I now

I think I found it. In InstCombiner::ComputeMaskedBits we have the following lines: if (GlobalValue *GV = dyn_cast<GlobalValue>(V)) { unsigned Align = GV->getAlignment(); if (Align == 0 && TD && GV->getType()->getElementType()->isSized()) Align = TD->getPrefTypeAlignment(GV->getType()->getElementType()); It assumes that global

Hi Clemens, > I'm instrumenting IR by replacing loads and stores by calls to a library, which > I have compiled to bitcode such that inlining can take place. My problem is: If > I could retain the alignment information on the load/store, this would open many > optimization opportunities after inlining. Unfortunately, I don't know how. > > After thinking about it, and