From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9473 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 09:14:57 +0300 (MSK) Message-ID: References: <20160305052459.GD9349@brightrain.aerifal.cx> <20160305055605.GF9349@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 1457158516 23166 80.91.229.3 (5 Mar 2016 06:15:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Mar 2016 06:15:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9486-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 05 07:15:11 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 1ac5Uc-0005m1-ND for gllmg-musl@m.gmane.org; Sat, 05 Mar 2016 07:15:10 +0100 Original-Received: (qmail 18315 invoked by uid 550); 5 Mar 2016 06:15:09 -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 18297 invoked from network); 5 Mar 2016 06:15:08 -0000 In-Reply-To: <20160305055605.GF9349@brightrain.aerifal.cx> User-Agent: Alpine 2.20 (LNX 67 2015-01-07) Xref: news.gmane.org gmane.linux.lib.musl.general:9473 Archived-At: On Sat, 5 Mar 2016, Rich Felker wrote: > > make it really obvious that __procfdname_impl fills in reverse; it might be a > > very minor size optimization. I don't mind dropping this add adjusting buf > > with '+= procfdbufsize - 1' in the callee. > > Yes, making it obvious what's going on is nice too. I'm going to keep that adjustment in the macro for now, then. > 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. I forgot to ask before, shouldn't __procfdname_impl have a visibility annotation? And likewise for other internal functions. There are some internal functions without hidden/internal visibility annotation, visible outside of libc.so. That seems unintended and slightly harmful. Alexander