r215614 - CodeGen: When bitfields fall on natural boundaries, split them up

Chandler Carruth chandlerc at google.com
Wed Aug 13 20:05:51 PDT 2014


On Wed, Aug 13, 2014 at 7:42 PM, Justin Bogner <mail at justinbogner.com>
wrote:

> Author: bogner
> Date: Wed Aug 13 21:42:10 2014
> New Revision: 215614
>
> URL: http://llvm.org/viewvc/llvm-project?rev=215614&view=rev
> Log:
> CodeGen: When bitfields fall on natural boundaries, split them up
>
> Currently when laying out bitfields that don't need any padding, we
> represent them as a wide enough int to contain all of the bits. This
> can be hard on the backend since we'll do things like represent stores
> to a few bits as loading an i144, masking it with a large constant,
> and storing it back.
>
> This turns up in less pathological cases where we load and mask 64 bit
> word on a 32 bit platform when we actually only need to access 32 bits.
> This leads to bad code being generated in most of our 32 bit backends.
>
> In practice, there are often natural breaks in bitfields, and it's a
> fairly simple and effective heuristic to split these fields into legal
> integer sized chunks when it will be equivalent (ie, it won't force us
> to add any extra padding).
>

Please revert. We used to do this, and I worked very hard to specifically
design the system to work the way it does now. There are copious comments,
email threads, and discussions where we debated how to handle this and
decided to do so in the exact way.

If you want to re-open the discussion, cool. But please do so as a
discussion, and cite specifically why the rationale for using fully-wide
loads and stores is inapplicable or causes insurmountable problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140813/73fdd3d6/attachment.html>


More information about the cfe-commits mailing list