<div dir="ltr">Right, but my question is "why completely change the existing bitvector type to try to accomplish this instead of make one for pdb, which has a very different set of use cases and priorities"<div>For BitVector, priority 1 is fast bit set/reset and set operations.</div><div>There is no priority #2</div><div><br></div><div>For PDB, it seems "being able to sanely read and write bitvector to disk is priority 1, set operation performance is number two.</div><div><br></div><div>At the point the priorities are basically diametrically opposed, *and* patches so far have shown trying to do both creates a bit of a mess, i'd create a new type.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 10, 2016 at 9:48 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Actually memcpy is exactly what we want to do.  The pdb's bits are in this order <br><br>7 6 5 4 3 2 1 0 | 15 14 13 12 11 10 9 8<br><br>But the bitvectors aren't, so a memcpy won't work.<br><br>Unless I've missed something <br><div class="HOEnZb"><div class="h5"><div class="gmail_quote"><div dir="ltr">On Wed, Aug 10, 2016 at 9:41 PM Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">FWIW: Speaking as a guy who wrote the bitvector and sparse bitvector implementations for a number of compilers, three generic data structure libraries,  and other random apps, not only would I never expect to access the underlying bytes in a bitvector, until this thread, i've never seen anyway nobody's ever asked to :)<div><br></div><div>In fact, they often asked for the opposite, and wanted them specialized to be as large a datatype as possible internally and then have the ops auto-vectorized (gcc, for example, does this: #define SBITMAP_ELT_TYPE unsigned HOST_WIDEST_FAST_INT to get the fastest datatype possible for it).</div><div><br></div><div>Is the PDB stuff so performance sensitive that you can't just create OnDiskBitVector and pay for the memcpy to copy a BitVector into one?<br></div><div><br></div><div>(Or, alternatively, use that type exclusively in the cases you need to put it on disk)</div><div><br></div><div>You also gain the advantage that you could specialize it so, for example, it's mmapable and thus only the parts you touch are actually read from disk.</div><div><br></div><div>--Dan</div></div><div dir="ltr"><div><br></div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 10, 2016 at 9:32 PM, Zachary Turner via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br><br>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.<div><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 10, 2016 at 9:25 PM Madhur Amilkanthwar <<a href="mailto:madhur13490@gmail.com" target="_blank">madhur13490@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I agree with David. You mentioned the reasons about design choices and things which would be allowed with this patch but what about performance?</div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 11, 2016 at 8:36 AM, David Majnemer via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">majnemer added a subscriber: majnemer.<br>
majnemer added a comment.<br>
<br>
Have you actually measured this to be a major improvement? Are there so many bits that the old way is a major bottleneck?<br>
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...<br>
</blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br>
<br>
<a href="https://reviews.llvm.org/D23384" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D23384</a><br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div></div><div class="gmail_extra"><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><i style="font-size:12.8px">Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this mail are of my own and my employer has no take in it. </i><br></div><div>Thank You.<br>Madhur D. Amilkanthwar<br><br></div></div></div>
</div></blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div></div></div></div></blockquote></div>
</div></div></blockquote></div><br></div>