| Summary: | To COMPILE_ASSERT bitfields are packed with expected size | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Yong Li <yong.li.webkit> |
| Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | aroben, bweinstein, cmarcelo, eric |
| Priority: | P4 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | |||
| Bug Blocks: | 17217 | ||
I suspect there may be a bunch of perf on the table for Safari Win due to these. See related bug 17217 for wider deployment of these COMPILE_ASSERTs. 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. |
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.