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

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.)

Thanks,
Hans

On Thu, Feb 11, 2016 at 4:16 PM, Hans Wennborg <hans at chromium.org>
wrote:
> Dear lots of people,
>
> The first comments on the 3.7 release expressed surprise that there
> were no changes to the X86 or ARM targets. There had of course been a
> lot of hard work and many changes, but none of it was mentioned in the
> release notes.
>
> Please help make the release notes more comprehensive this time. The
> notes are of course not as important as the actual code, but they do
> get read, and they are a good way of telling users about all the hard
> work you have done in the past six months.
>
> If you made any changes in the 3.8 time span that might be worth
> mentioning, please add them to the release notes --- it does not have
> to be big-ticket items. If you saw someone else commit something
> interesting, prod them to write a note about it.

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.

Joerg

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.

Cheers,
Hans