<div class="gmail_quote">On Mon, Jan 16, 2012 at 8:32 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Jan 16, 2012, at 5:24 PM, Jakob Stoklund Olesen wrote:<br>
<br>
> Author: stoklund<br>
> Date: Mon Jan 16 19:24:32 2012<br>
> New Revision: 148272<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=148272&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=148272&view=rev</a><br>
> Log:<br>
> Add portable bit mask operations to BitVector.<br>
><br>
> BitVector uses the native word size for its internal representation.<br>
> That doesn't work well for literal bit masks in source code.<br>
><br>
> This patch adds BitVector operations to efficiently apply literal bit<br>
> masks specified as arrays of uint32_t.  Since each array entry always<br>
> holds exactly 32 bits, these portable bit masks can be source code<br>
> literals, probably produced by TableGen.<br>
<br>
</div>Out of curiosity, why not arrays of uint64_t?  It will be faster on 64-bit platforms, and shouldn't really be a penalty on 32-bit either.<br></blockquote><div><br></div><div>I wondered the same thing. I also wondered about an array of indices rather than an array of bits.. Specifically, an array of indices would seem easier to read, and if they're all likely to be literals, I would expect the optimizer to make them all equivalent...</div>
</div>