From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12131 Path: news.gmane.org!.POSTED!not-for-mail From: David Guillen Fandos Newsgroups: gmane.linux.lib.musl.general Subject: Re: Do not use 64 bit division if possible Date: Sun, 26 Nov 2017 02:12:58 +0100 Message-ID: References: <424674f0-8460-7807-7366-a87d8588e8bc@davidgf.es> <9716E0B3-B86C-4CFF-8636-6DE4BAA0D716@mac.com> <5575a0c9-0f53-f8e7-e0dc-6c1ff2b594f7@davidgf.es> <20171125235333.GQ1627@brightrain.aerifal.cx> <796e366e-f321-25a3-78e7-8a3800e62eeb@davidgf.es> <20171126005916.GS1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1511658798 32637 195.159.176.226 (26 Nov 2017 01:13:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Nov 2017 01:13:18 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 To: musl@lists.openwall.com Original-X-From: musl-return-12147-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 26 02:13:14 2017 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.84_2) (envelope-from ) id 1eIlVL-0007jZ-0a for gllmg-musl@m.gmane.org; Sun, 26 Nov 2017 02:13:07 +0100 Original-Received: (qmail 7443 invoked by uid 550); 26 Nov 2017 01:13:12 -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 7425 invoked from network); 26 Nov 2017 01:13:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=davidgf-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=VRmhdELWxESwnFTt0qbC7u504eEwvryXHdI+rDQb/8s=; b=V84QcU/OFnvOCwmOGP0eD5RhpbeHO5gzUsuQYCeHKkxcKiOd5vu0oxGdiAdbhWzlae sIRilpXFXLTWMZWsc3VGSmmlWsImTwW4gPjwyshhQkrBXYXSSxBLPYUP9oKfCxWIGciE wH9/AK6Gs5LPWb6hQCBkkq3o7tiBckFrBl/WO9+sdE/Kh0e6xgqZjM+Yn6ODrjDOlCwk QNxnFCAxrYWa+TCu1QLHIBbDjAUKvr4NeXbVcB2G2luXPEtxtbMwFxhrX+lsj0Bh3ScS cY3fU3x6jxbw4zQT+0/86nU/PZ116X5HcsBo0zh9Bsep7lnVNebCz/3JKguKP01j4Mjv zV2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VRmhdELWxESwnFTt0qbC7u504eEwvryXHdI+rDQb/8s=; b=E11Z5pqatnlWOZurgxy9kTofwuMEqUbnJfWLiRXjm8aNV0jSXnm66Iwv6qfRwExuWk +18fZQUBSGKv5MEF/88Q4KUvEY+lH8XGo3GULLQGqfYpIQ0rCmkSwpFbXFE3Gf4PbRzy zUkWsMF8mFYAdvCXZEJmdDGsUWapSYaYMWxMyE4SBaToMgZ/f1aZOYmoNJl1wjnWe+rm ZJSiezM1EcRnPWGXw+tyEtQhDEQAmlTIIeLqPjVfnrjCXruBXaypNdLdz0rshNNovItA 2KBm7j/a7h5GbgOohraEw0y1EemZqrl+Lr1EZ04/OXOb0kaLzJnp1PTL+IOIlIc2pvnv J5fA== X-Gm-Message-State: AJaThX6SoPzB4Kp5APE9Y1WjCcBwFFVnUPh8NKfHhzRp6YnTjMrBMwdb lgwVOQLujwfqNCisYb3wAx1rT6Ew9Q== X-Google-Smtp-Source: AGs4zMbLf9vHbfmRbsKjyG5bLWr+AN1L9VOCYM/+2HTengTiBS+JVYHngzwbpEv4pcnaMEC8g0HZKg== X-Received: by 10.80.145.14 with SMTP id e14mr34905064eda.34.1511658780004; Sat, 25 Nov 2017 17:13:00 -0800 (PST) In-Reply-To: <20171126005916.GS1627@brightrain.aerifal.cx> Content-Language: en-US Xref: news.gmane.org gmane.linux.lib.musl.general:12131 Archived-At: On 26/11/17 01:59, Rich Felker wrote: > On Sun, Nov 26, 2017 at 01:49:09AM +0100, David Guillen Fandos wrote: >> Hey, >> >> Wow that's an awesome optimization (the a&-a), didn't know gcc was >> smart enough to figure that out by itself :D > > It doesn't seem to be doing any optimizing for me. What it *should* do > is optimize the div to ctz+shift. > > BTW please don't top-reply; it makes threads hard to follow and hard > to meaningfully reply to inline. > > Rich > > >> I just realized that PAGE_SIZE seems indeed to be defined to a >> constant for some architectures, did not notice since I was running >> on MIPS which has a page size different for each uarch. >> >> I'd say the (a&-a) is a very simple optimization and we should use >> it, since it adds almost no complexity and sames some cycles and >> some .text bytes, which is sometimes a bit tight. >> >> Something like this? Doesn't hurt constants, improves some arches :) >> >> diff --git a/src/conf/sysconf.c b/src/conf/sysconf.c >> index b8b761d0..aa9fc9d1 100644 >> --- a/src/conf/sysconf.c >> +++ b/src/conf/sysconf.c >> @@ -206,7 +206,7 @@ long sysconf(int name) >> if (name==_SC_PHYS_PAGES) mem = si.totalram; >> else mem = si.freeram + si.bufferram; >> mem *= si.mem_unit; >> - mem /= PAGE_SIZE; >> + mem /= (unsigned)(PAGE_SIZE & -PAGE_SIZE); >> return (mem > LONG_MAX) ? LONG_MAX : mem; >> case JT_ZERO & 255: >> return 0; Sorry for that, default settings you know :) Well the main reason is cause in MIPS it requires adding __divdi3 which is around 1KB of code, which hey, it's not much, but why would we need it right? It makes a difference in embedded tools with statically linked musl. Thanks for your interest! David