[cfe-commits] [Patch] -Wduplicate-enum which fixes PR6343

[Richard Trieu]

On Tue, Aug 14, 2012 at 9:48 PM, Ted Kremenek <kremenek at apple.com> wrote:

> On Aug 14, 2012, at 2:32 PM, Richard Trieu <rtrieu at google.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120815/438101bd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: duplicate-enum-densemap.patch
Type: application/octet-stream
Size: 8528 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120815/438101bd/attachment.obj>