[PATCH] D23384: Use a byte array as an internal buffer of BitVector.

Zachary Turner via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 10 21:32:53 PDT 2016


It's worth profiling but I would imagine performance to be the same or
faster. Conceptually the only difference is storing longs internally or
bytes internally. The latter allows fewer bitwise operations on average to
extract or set a given bit, so i would imagine performance to be the same
or faster. Regardless, since this is a performance sensitive data
structure, we should profile.

Design wise, i think this actually makes it more generic, not less. If you
have a bit vector, it's reasonable to expect you can access the underlying
bytes, but you can't when the internal representation is a sequence of
longs.

On Wed, Aug 10, 2016 at 9:25 PM Madhur Amilkanthwar <madhur13490 at gmail.com>
wrote:

> I agree with David. You mentioned the reasons about design choices and
> things which would be allowed with this patch but what about performance?
>
> On Thu, Aug 11, 2016 at 8:36 AM, David Majnemer via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>> majnemer added a subscriber: majnemer.
>> majnemer added a comment.
>>
>> Have you actually measured this to be a major improvement? Are there so
>> many bits that the old way is a major bottleneck?
>> The BitVector is used for the CodeGen and optimizer, I'm not entirely
>> convinced it makes sense to modify this generic datastructure so
>> drastically for PDBs...
>>
>
>>
>> https://reviews.llvm.org/D23384
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>
>
>
> --
> *Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this
> mail are of my own and my employer has no take in it. *
> Thank You.
> Madhur D. Amilkanthwar
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160811/669c8261/attachment.html>


More information about the llvm-commits mailing list