[cfe-dev] [3.8 Release] Please write release notes!
John McCall via cfe-dev
cfe-dev at lists.llvm.org
Mon Mar 7 09:47:07 PST 2016
> On Mar 7, 2016, at 9:24 AM, Hans Wennborg <hans at chromium.org> wrote:
> On Wed, Mar 2, 2016 at 11:34 PM, John McCall <rjmccall at apple.com> wrote:
>>> On Feb 26, 2016, at 9:16 AM, Hans Wennborg via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>>> If you were thinking about writing a note for 3.8 but didn't get
>>> around to it yet, this is the final reminder.
>>>
>>> (In particular, the notes for X86 and PowerPC could use some attention.)
>>
>> You asked for a release note about alignment; here you go.
>>
>> --
>>
>> Alignment
>>
>> Clang has gotten better at passing down strict type alignment information to LLVM,
>> and several targets have gotten better at taking advantage of that information.
>>
>> Dereferencing a pointer that is not adequately aligned for its type is undefined
>> behavior. It may crash on target architectures that strictly enforce alignment, but
>> even on architectures that do not, frequent use of unaligned pointers may hurt
>> the performance of the generated code.
>>
>> If you find yourself fixing a bug involving an inadequately aligned pointer, you
>> have several options.
>>
>> The best option, when practical, is to increase the alignment of the memory.
>> For example, this array is not guaranteed to be sufficiently aligned to store
>> a pointer value:
>>
>> char buffer[sizeof(const char*)];
>>
>> Writing a pointer directly into it violates C's alignment rules:
>>
>> ((const char**) buffer)[0] = “Hello, world!\n”;
>>
>> But you can use alignment attributes to increase the required alignment:
>>
>> __attribute__((aligned(__alignof__(const char*))))
>> char buffer[sizeof(const char*)];
>>
>> 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));
>>
>> You may also override the default alignment assumptions of a pointer by
>> using a typedef with explicit alignment:
>>
>> typedef const char *unaligned_char_ptr __attribute__((aligned(1)));
>> ((unaligned_char_ptr*) buffer)[0] = “Hello, world!\n”;
>>
>> The final option is to copy the memory into something that is properly
>> aligned. Be aware, however, that Clang will assume that pointers are
>> properly aligned for their type when you pass them to a library function
>> like memcpy. For example, this code will assume that the source and
>> destination pointers are both properly aligned for an int:
>>
>> void copy_int_array(int *dest, const int *src, size_t num) {
>> memcpy(dest, src, num * sizeof(int));
>> }
>>
>> You may explicitly disable this assumption by casting the argument to a
>> less-aligned pointer type:
>>
>> void copy_unaligned_int_array(int *dest, const int *src, size_t num) {
>> memcpy((char*) dest, (const char*) src, num * sizeof(int));
>> }
>>
>> Clang promises not to look through the explicit cast when inferring the
>> alignment of this memcpy.
>>
>> --
>
> Many thanks; r262836.
>
> Unfortunately, the 'final' tag had already been created when you sent
> this, so users building the release notes from 3.8.0 sources won't get
> it. Since it seems important, I'll include it when building the 3.8
> release notes for the web, though.
Thanks. Sorry for being slow about it.
John.
More information about the cfe-dev
mailing list