From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/15024 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: max_align_t mess on i386 Date: Sun, 15 Dec 2019 13:22:42 -0500 Message-ID: <20191215182242.GA1666@brightrain.aerifal.cx> References: <20191214151932.GW1666@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="106241"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-15040-gllmg-musl=m.gmane.org@lists.openwall.com Sun Dec 15 19:23:01 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1igYXh-000RQs-6x for gllmg-musl@m.gmane.org; Sun, 15 Dec 2019 19:22:57 +0100 Original-Received: (qmail 15579 invoked by uid 550); 15 Dec 2019 18:22:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 15561 invoked from network); 15 Dec 2019 18:22:54 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:15024 Archived-At: On Sun, Dec 15, 2019 at 01:06:29PM -0500, Jeffrey Walton wrote: > On Sat, Dec 14, 2019 at 10:19 AM Rich Felker 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