Re: max_align_t mess on i386

[Rich Felker <dalias@libc.org>]

On Sun, Dec 15, 2019 at 01:06:29PM -0500, Jeffrey Walton wrote:
> On Sat, Dec 14, 2019 at 10:19 AM Rich Felker <dalias@libc.org> wrote:
> >
> > In reserching how much memory could be saved, and how practical it
> > would be, for the new malloc to align only to 8-byte boundaries
> > instead of 16-byte on archs where alignof(max_align_t) is 8 (pretty
> > much all 32-bit archs), I discovered that GCC quietly changed its
> > idead of i386 max_align_t to 16-byte alignment in GCC 7, to better
> > accommodate the new _Float128 access via SSE. Presumably (I haven't
> > checked) the change is reflected with changes in the psABI document to
> > make it "official".
> 
> Be careful with policy changes like this. The malloc (3) man page says:

Generally, you should look to the C11 or POSIX (man 3p) specifications
for the functions rather than the "man 3" ones, but here it's pretty
close to the same, just imprecisely worded:

>     The malloc() and calloc() functions return a pointer to the
>     allocated memory that is suitably aligned for any kind of variable.
> 
> I expect to be able to use a pointer returned by malloc (and friends)
> in MMX, SSE and AVX functions.

"Any kind of variable" isn't "any kind of load/store instruction". For
example you most certainly will not get 32- or 64-byte alignment that
you may want for AVX-256 or AVX-512 without memalign. A max_align_t
(and corresponding malloc alignment constraint) that heavily aligned
would be awful to use, with memory waste possibly exceeding 1000% and
over 500% likely for real-world data structures. Over-alignment also
weakens hardening properties by making pointers more predictable.

Rich