[cfe-dev] [llvm-dev] [3.8 Release] Please write release notes!

Joerg Sonnenberger via cfe-dev cfe-dev at lists.llvm.org
Sun Mar 6 15:23:06 PST 2016


On Fri, Mar 04, 2016 at 02:47:42PM -0800, John McCall wrote:
> > On Mar 3, 2016, at 6:05 AM, Joerg Sonnenberger via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> > On Wed, Mar 02, 2016 at 11:34:27PM -0800, John McCall via llvm-dev wrote:
> >> When that’s not practical, you can instead reduce the alignment requirements
> >> of the pointer.  If the pointer is to a struct that represents that layout of a
> >> serialized structure, consider making that struct packed; this will remove any
> >> implicit internal padding that the compiler might add to the struct and
> >> reduce its alignment requirement to 1.
> >> 
> >>  struct file_header {
> >>    uint16_t magic_number;
> >>    uint16_t format_version;
> >>    uint16_t num_entries;
> >>  } __attribute__((packed));
> > 
> > If we want to include this example, it is likely a good idea to point
> > out that packed and aligned can be combined, i.e. if you know that the
> > file_header copies are going to be at an aligned location, adding the
> > attribute results in significantly better code on platforms like ARM
> > with strict alignment.
> 
> I’d like to keep the release note relatively focused on our recommended ways
> to fix alignment bugs.

I've seen a lot of cases where packed was used like above and it had a
pretty serious performance impact the first time the code was used on
ARM or other strict alignment architecture. Often packed is used when
not strictly necessary or when there is still a decent base alignment of
the storage. Just recommending something that kills performance is not a
good recommendation, IMO.

Joerg


More information about the cfe-dev mailing list