On Tue, Aug 14, 2012 at 9:48 PM, Ted Kremenek <[email protected]> wrote:
> On Aug 14, 2012, at 2:32 PM, Richard Trieu <[email protected]> wrote: > > At a high level, I honestly find this logic to be more complicated than >> I would have expected. The sorting seems unnecessary, and will report >> diagnostics in an unnatural order (first based on enum constant value, then >> on declaration order). A straight linear pass seems more naturally to me, >> and DenseMap is very efficient. >> > Is there a comparison between the different containers in LLVM and the STL > containers? > > > This is a reasonable place to start: > > http://llvm.org/docs/ProgrammersManual.html#ds_map > > The key with DenseMap is that it is probed hashtable. There is one big > allocation for the entire table, instead of a bunch of buckets. When > applicable, it can be very fast, and feels like the right data structure to > use here. > Duplicate enum detection, now with DenseMap. The DenseMap maps a int64_t to a vector pointer. 0 and 1 were special keys for the DenseMap, so two separate pointers special cased for them. The vectors pointers are stored in another vector in declaration order. One pass is made over the enums to find ones without initializers. These are used to create vectors. A second pass through the enums populates the vectors. Finally, a pass over the vector of vectors is used to generate all the warnings and notes. Run time is fairly consistent with the sorted vector implementation, which is max %3 difference against control.
duplicate-enum-densemap.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
