On Wed, May 15, 2013 at 11:15 AM, <da...@chromium.org> wrote: > > https://codereview.chromium.**org/14284010/diff/56001/src/** > hydrogen-instructions.h<https://codereview.chromium.org/14284010/diff/56001/src/hydrogen-instructions.h> > File src/hydrogen-instructions.h (right): > > https://codereview.chromium.**org/14284010/diff/56001/src/** > hydrogen-instructions.h#**newcode5267<https://codereview.chromium.org/14284010/diff/56001/src/hydrogen-instructions.h#newcode5267> > src/hydrogen-instructions.h:**5267: unsigned portion_ : 4; > I think you misinterpreted my comment. With unsigned, you only need 3 > bits, but with the enum type, you need 4. I am not sure why you don't > think this will work, we do it elsewhere. If you are worried that the > compiler won't pack, then please use a single field unsigned bit_field_; > and define strongly-type BitFields for both parts. That approach is > guaranteed to work. >
I verified that gcc chooses not to pack the portion_ field if it is declared as Portion on ia32 linux, resulting in a 12 byte object (versus 8 packed). I am looking at these uses of BitField elsewhere and think that it would be a very significant reduction in readability and usability to use it in this circumstance. Rather, I'd prefer the readable code and I think the asserts in the constructor should defend against the brittleness that BitField supposedly avoids. https://codereview.chromium.**org/14284010/<https://codereview.chromium.org/14284010/> > -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
