search for: sparsebitvectors

The warning is: R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(58) : warning C4099: 'llvm::ilist_sentinel_traits<llvm::SparseBitVectorElement<ElementSize>>' : type name first seen using 'struct' now seen using 'class' R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(275) : see reference to class template instantiation

Hi all, Did someone forget to check-in a patch? I'm getting this error during compilation on PPC: /Volumes/SandBox/Clean/llvm-9999-01.roots/llvm-9999-01~obj/src/llvm/lib/Analysis/IPA/Andersens.cpp: In function 'void dumpToDOUT(llvm::SparseBitVector<128u>*)': /Volumes/SandBox/Clean/llvm-9999-01.roots/llvm-9999-01~obj/src/llvm/lib/Analysis/IPA/Andersens.cpp:1189: error: no

A debug or release build? -bw On Sep 24, 2007, at 2:36 PM, Dale Johannesen wrote: > > On Sep 24, 2007, at 2:29 PM, Bill Wendling wrote: > >> Hi all, >> >> Did someone forget to check-in a patch? I'm getting this error during >> compilation on PPC: > > A recent checkout compiled fine for me (on x86). > >>

On Sep 24, 2007, at 2:29 PM, Bill Wendling wrote: > Hi all, > > Did someone forget to check-in a patch? I'm getting this error during > compilation on PPC: A recent checkout compiled fine for me (on x86). > /Volumes/SandBox/Clean/llvm-9999-01.roots/llvm-9999-01~obj/src/llvm/ > lib/Analysis/IPA/Andersens.cpp: > In function 'void

Here is the latest shrink wrapping patch, with fixes for issues identified by Evan. I am including a few small additions/fixes to include/llvm/ADT/{SparseBitVector,DepthFirstIterator}.h. Files: include/llvm/ADT/DepthFirstIterator.h include/llvm/ADT/SparseBitVector.h lib/CodeGen/PrologEpilogInserter.cpp Evan, let me know how it looks when you get a chance. Thanks much, John >

On Sep 24, 2007, at 3:07 PM, Bill Wendling wrote: > A debug or release build? > > -bw Both, actually. > On Sep 24, 2007, at 2:36 PM, Dale Johannesen wrote: > >> >> On Sep 24, 2007, at 2:29 PM, Bill Wendling wrote: >> >>> Hi all, >>> >>> Did someone forget to check-in a patch? I'm getting this error >>> during

On Sep 24, 2007, at 3:15 PM, Dale Johannesen wrote: > > On Sep 24, 2007, at 3:07 PM, Bill Wendling wrote: > >> A debug or release build? >> >> -bw > > Both, actually. Weird. I see a potential problem, though. The code is like this: void dumpToDOUT(SparseBitVector<> *bitmap) { dump(*bitmap, DOUT); } where dump expects an llvm::OStream& for the

On 9/4/07, Devang Patel <dpatel at apple.com> wrote: > > On Sep 4, 2007, at 4:36 PM, Daniel Berlin wrote: > > [snip] > > Don't forget to update ProgrammersManual.html "Picking the Right > Data Structure for a Task" section. :) It doesn't talk about bitvector at all. I'm not sure whether i should add it to set like containers, or add a section

On Tue, 4 Sep 2007, Daniel Berlin wrote: >> insert/push_back without making copies. Either of these approaches would >> also fix what looks like a leak in operator&=, where elements are erased >> from the list without being deleted. > > I seriously considered not using indirection, but it made a lot of the > functions more annoying, and it didn't seem worth the

On 9/4/07, Dan Gohman <djg at cray.com> wrote: > On Tue, Sep 04, 2007 at 10:35:10AM -0400, Daniel Berlin wrote: > > On 9/4/07, Dan Gohman <djg at cray.com> wrote: > > > On Fri, Aug 31, 2007 at 08:10:33PM -0400, Daniel Berlin wrote: > > > > + template <int ElementSize> > > > > + class SparseBitmap { > > > > > > Do you

Hi John, Unless anyone else has any comments. I recommend you check in the PEI patches so we can start testing it as llcbeta. Chris, should I commit the patch for John or can you grant him commit access (since part of his patch has already been committed)? Evan On Mar 16, 2009, at 3:23 PM, John Mosby wrote: > Here is the latest shrink wrapping patch, with fixes for issues >

LGTM. Was that the last use of SparseBitVector? Thanks, /jakob > On 30 Oct 2013, at 22:34, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> On 30 October 2013 20:08, Evan Cheng <evan.cheng at apple.com> wrote: >> The current implementation in LLVM is experimental at best. It probably should be ripped out. > > Patch attached :-) > >

On 9/24/07, Bill Wendling <isanbard at gmail.com> wrote: > On Sep 24, 2007, at 3:15 PM, Dale Johannesen wrote: > > > > > On Sep 24, 2007, at 3:07 PM, Bill Wendling wrote: > > > >> A debug or release build? > >> > >> -bw > > > > Both, actually. > > Weird. I see a potential problem, though. The code is like this: > >

On 9/25/07, Daniel Berlin <dberlin at dberlin.org> wrote: > On 9/24/07, Bill Wendling <isanbard at gmail.com> wrote: > > On Sep 24, 2007, at 3:15 PM, Dale Johannesen wrote: > > > > Weird. I see a potential problem, though. The code is like this: > > > > void dumpToDOUT(SparseBitVector<> *bitmap) { > > dump(*bitmap, DOUT); > > } >

Changing a header file somewhere and having to spend 10 minutes waiting for a build leads to a lot of wasted developer time. The real culprit here is tablegen. Can we split support and ADT into two - the parts that tablegen depends on and the parts that it doesn't? >From what I can gather, Tablegen currently depends on these headers and all of their transitive dependencies. #include

On 9/7/07, Chris Lattner <sabre at nondot.org> wrote: > On Tue, 4 Sep 2007, Daniel Berlin wrote: > >> insert/push_back without making copies. Either of these approaches would > >> also fix what looks like a leak in operator&=, where elements are erased > >> from the list without being deleted. > > > > I seriously considered not using indirection,

On Fri, Aug 31, 2007 at 08:10:33PM -0400, Daniel Berlin wrote: > Suggestions, criticisms, etc, are welcome. I haven't studied the implementation, but I have a few comments on the interface, and some style comments, below. > Index: include/llvm/ADT/SparseBitmap.h > =================================================================== > --- include/llvm/ADT/SparseBitmap.h (revision

I just enabled a new algorithm for computing live intervals that doesn't depend on LiveVariables. The goal is to get rid of the LiveVariables analysis completely, but unfortunately PHI elimination and the two-address pass still use LiveVariables for some optimizations. They don't require it, they work just fine without it at -O0. They use it to generate better code in some cases. The

The attached patch adds a SparseBitmap implementation, which more or less works the same way as GCC's sparse bitmap. That is, we only store non-zero bits (broken up into elements of some bit size), and store the elements in a linked list. We keep track of the last accessed part of the linked list, so in-order tests/sets/resets are all constant time, rather than linear time. Set operations

It would be better, because a debug tablegen is slower than an optimized tablegen, but it's still slow and it doesn't address the problem that tablegen runs *at all* when it doesn't really need to. I think if tablegen wasn't running all the time we could incremental builds down from 15 minutes (and that's on my really powerful machine) to under 5, which seemed like a big