Bug 55088 - To COMPILE_ASSERT bitfields are packed with expected size
Summary: To COMPILE_ASSERT bitfields are packed with expected size
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P4 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 17217
  Show dependency treegraph
 
Reported: 2011-02-23 15:00 PST by Yong Li
Modified: 2011-04-12 22:01 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yong Li 2011-02-23 15:00:31 PST
How bitfields are packed relies on compiler implementation. For example:

struct {
int x : 31;
bool y : 1;
};

Above struct consumes 8 bytes in MSVC, where we probably expect it uses only 4 bytes (otherwise why do we even use bitfields?). Unfortunately, we are widely using this pattern in webkit.

More information:

http://msdn.microsoft.com/en-us/library/hx1b6kkd.aspx

"Adjacent bit fields are packed into the same 1-, 2-, or 4-byte allocation unit if the integral types are the same size and if the next bit field fits into the current allocation unit without crossing the boundary imposed by the common alignment requirements of the bit fields. "

Ideally, we should be able to assert bitfields are packed with expected size at compile time. Also it would be nice if check-webkit-style can detect such issues.
Comment 1 Eric Seidel (no email) 2011-03-22 16:28:40 PDT
I suspect there may be a bunch of perf on the table for Safari Win due to these.
Comment 2 Eric Seidel (no email) 2011-03-22 16:29:28 PDT
See related bug 17217 for wider deployment of these COMPILE_ASSERTs.
Comment 3 Adam Roben (:aroben) 2011-03-23 08:25:08 PDT
It seems like there are two bugs here:

1) There are places in WebKit that have suboptimal bitfield packing
2) We would like to assert that bitfield packing is optimal

(2) seems very similar to bug 17217. (1) probably needs to be split out into multiple bugs.