|
Message-ID: <20191215182242.GA1666@brightrain.aerifal.cx> Date: Sun, 15 Dec 2019 13:22:42 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: max_align_t mess on i386 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@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.