From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9474 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [RFC PATCH] micro-optimize __procfdname Date: Sat, 5 Mar 2016 01:20:19 -0500 Message-ID: <20160305062019.GH9349@brightrain.aerifal.cx> 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 1457158837 27325 80.91.229.3 (5 Mar 2016 06:20:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Mar 2016 06:20:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9487-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 05 07:20:37 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 1ac5Zs-0000x0-1t for gllmg-musl@m.gmane.org; Sat, 05 Mar 2016 07:20:36 +0100 Original-Received: (qmail 21905 invoked by uid 550); 5 Mar 2016 06:20:34 -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 21878 invoked from network); 5 Mar 2016 06:20:33 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9474 Archived-At: On Sat, Mar 05, 2016 at 09:14:57AM +0300, Alexander Monakov wrote: > 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. OK. > > 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. > 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. Yes, I'd go with only _slightly_ harmful because visibility does not help with static linking. But of course in the static case you don't have to worry about ABI-compat with future libc versions. I've thought about having libc.h define a macro simply named "hidden" for declaring things with hidden visibility; then files needing it could just include libc.h and do stuff like: hidden char *__procfdname_impl(...); This would be more a matter of de-uglification than abstraction. Does anyone particularly like or hate this idea? Rich