From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9477 Path: news.gmane.org!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: Re: [RFC PATCH] micro-optimize __procfdname Date: Sat, 5 Mar 2016 18:13:43 +0300 (MSK) Message-ID: References: <20160305052459.GD9349@brightrain.aerifal.cx> <20160305055605.GF9349@brightrain.aerifal.cx> <20160305062019.GH9349@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1457190841 23671 80.91.229.3 (5 Mar 2016 15:14:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Mar 2016 15:14:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9490-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 05 16:13:58 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1acDu2-0004Oi-LF for gllmg-musl@m.gmane.org; Sat, 05 Mar 2016 16:13:58 +0100 Original-Received: (qmail 19911 invoked by uid 550); 5 Mar 2016 15:13: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 19890 invoked from network); 5 Mar 2016 15:13:54 -0000 In-Reply-To: <20160305062019.GH9349@brightrain.aerifal.cx> User-Agent: Alpine 2.20 (LNX 67 2015-01-07) Xref: news.gmane.org gmane.linux.lib.musl.general:9477 Archived-At: On Sat, 5 Mar 2016, Rich Felker wrote: > > > Actually it would be even nicer if we could use a compound literal > > > inside the macro as the buffer, but that would pessimize with > > > unnecessary initialization and eliminate a lot of the code-size > > > benefit, I think. > > > > Yep, I did consider that and arrived to a similar conclusion. Well, there's an > > option of using alloca as long as no use is in a loop, but that's a bit uglier, > > and as I recall it wasn't optimized to a static stack allocation. > > Yeah, alloca is a lot uglier, an extra extension we don't currently > use, and not something I would want to add. There's an option of returning a struct containing both a buffer and a pointer, but it's a bit worse code-size-wise and may be too magic: struct procfdname_ret { char *ptr, buf[procfdsize]; } __procfdname_impl(unsigned fd); #define procfdname(fd) __procfdname_impl(fd).ptr ... and in __procfdname_impl assign a pointer to last filled position in retval.buf to retval.ptr. OTOH this allows further cleanup of call sites. WDYT? Alexander