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

John McCall via llvm-dev llvm-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 llvm-dev mailing list