similar to: [LLVMdev] live variable analysis

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

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

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

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

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

David/All, Just a quick question about NSW/NUW bits, if you've got a second. I noticed you've been doing a little work on this as of late. I have a bit of code that looks like the following: %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1 %2 = add i64 %indvars.iv.next, -1 %tmp = trunc i64 %2 to i32 %cmp = icmp slt i32 %tmp, %0 br i1 %cmp, label %for.body, label

Hello LLVM, A recent commit creates the isIntDivCheap() target query. http://reviews.llvm.org/D12082 The current approach has a couple shortcomings. First, when targets decide divide is cheap, the DAGCombiner ignores obvious power-of-2 optimizations. In the targets I know, shifts are cheaper than divides in both speed and size. The target cannot see the value in the isIntDivCheap() call, so

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

Hi, how can i correctly calculate the size of a member of a struct (including alignment etc)? This doesn't work : const StructType *STy = cast<StructType>(Ty); for (StructType::element_iterator I = STy->element_begin(), E = STy->element_end(); I != E; ++I) { usigned size =I->get()->getScalarSizeInBits(); //often

Hi all In unittests/ADT/APIntTest.cpp I came across this test: // XFAIL this test on FreeBSD where the system gcc-4.2.1 seems to miscompile it. #if defined(__llvm__) || !defined(__FreeBSD__) TEST(APIntTest, i33_Count) { APInt i33minus2(33, static_cast<uint64_t>(-2), true); EXPECT_EQ(0u, i33minus2.countLeadingZeros()); EXPECT_EQ(32u, i33minus2.countLeadingOnes()); EXPECT_EQ(33u,

On Sun, 24 Jun 2012 14:44:45 +0200 Tobias Grosser <tobias at grosser.es> wrote: > On 06/24/2012 02:42 PM, Hal Finkel wrote: > > On Sun, 24 Jun 2012 08:17:32 +0200 > > Tobias Grosser<tobias at grosser.es> wrote: > > > >> On 06/24/2012 05:42 AM, Hal Finkel wrote: > >>> On Thu, 21 Jun 2012 16:25:13 +0200 > >>> Tobias

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

Hi, while using this function I noticed that Type::getScalarSizeInBits() is not marked as const even if inside its body it just uses only other "const" functions and types. This prevents the usage of the function through const pointers/references to Type without any apparent reason. I propose of marking the function as const. (attached is a patch that does so). Cheers, Marcello --

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, The full trace stack: Type set is empty for each HW mode: possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records). vtInt: (vt:{ *:[Other] }) UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824! [ 85%] Building X86GenEVEX2VEXTables.inc... &nbsp;#0 0x000000000081b9b5

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 =

On 5/16/2017 6:30 AM, Sanjay Patel wrote: > Thanks for posting this question, Julia. > > I had a similar question about a signed min/max variant here: > http://lists.llvm.org/pipermail/llvm-dev/2016-November/106868.html > > The 2nd version in each case contains a canonical max/min > representation in IR, and this could enable more IR analysis. > A secondary advantage is