From owner-freebsd-current@freebsd.org Sun Oct 8 07:28:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECDDDE2B305 for ; Sun, 8 Oct 2017 07:28:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E6797E316 for ; Sun, 8 Oct 2017 07:28:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16016 invoked from network); 8 Oct 2017 07:28:31 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 07:28:31 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 08 Oct 2017 03:28:31 -0400 (EDT) Received: (qmail 26251 invoked from network); 8 Oct 2017 07:28:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 07:28:30 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0B26FEC8559; Sun, 8 Oct 2017 00:28:30 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc Date: Sun, 8 Oct 2017 00:28:29 -0700 References: <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> <20171007064249.GA73770@vlakno.cz> <934C1C1A-1303-4A8C-9E80-4259E475220A@dsl-only.net> <20171007102151.GA84155@vlakno.cz> <08CBC862-4EAB-4864-B689-1949329EF3CE@dsl-only.net> To: Roman Divacky , Justin Hibbits , Warner Losh , FreeBSD Current In-Reply-To: <08CBC862-4EAB-4864-B689-1949329EF3CE@dsl-only.net> Message-Id: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Oct 2017 07:28:33 -0000 [I should have checked for 3 digit numerals in r notation.] On 2017-Oct-7, at 11:36 PM, Mark Millard wrote: > With a fresh day after sleep and some pondering > I finally am thinking straight for where things > are in files for C++ scratch register usage and > such: >=20 > It is libgcc_s.so.1 that has all the extra use of > scratch registers for C++ exception handling --and > lots of other special stuff as well. >=20 > This note is just about overall counts of example > usages in devel/powerpc64-gcc vs. clang processing > the same libgcc_s source. it gives a clue about > what coverage is going to be necessary. >=20 >=20 > So the compare/contrast is of: > (shown as seen in my context) >=20 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 > vs. > # dwarfdump -v -v -F /lib/libgcc_s.so.1 >=20 > (That last being from a clang-based buildworld and the > first being from a devel/powerpc64-xtoolchain-gcc > material based buildworld.) >=20 > Using r2 through r6 as initial examples: >=20 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc > 43 2683 18432 >=20 > vs. >=20 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "\" | wc > 0 0 0 >=20 > That is an example of missing information from clang. >=20 > For powerpc64-gcc it is interesting that. . . >=20 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc > 23 2063 14308 >=20 > but: >=20 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc > 27 2571 17800 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc > 27 2571 17800 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc > 27 2571 17800 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc > 27 2571 17800 >=20 > and: >=20 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc > 0 0 0 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc > 0 0 0 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc > 0 0 0 >=20 > Looks like r2 might sometimes be a scratch or otherwise > special register during C++ exception handling --but not > everyplace that r3-r6 are. >=20 > There are lots of other special r names with numerals > beyond that in the name r31 (powerpc64-gcc context): >=20 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r3[2-9]" | wc > 0 0 0 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r4[0-9]" | wc > 64 3248 22391 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r5[0-9]" | wc > 124 3548 24183 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r6[0-9]" | wc > 344 6978 49690 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r7[0-9]" | wc > 46 2314 16176 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r8[0-9]" | wc > 0 0 0 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r9[0-9]" | wc > 0 0 0 >=20 > Overall for > 31: >=20 > # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | egrep "(r3[2-9]|r[4-9][0-9])" | wc > 505 7867 55379 >=20 >=20 > By contrast from clang for > 31: >=20 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | egrep = "(r3[2-9]|r[4-9][0-9])" | wc > 254 3110 21110 >=20 > with the more detailed split out being: >=20 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r3[2-9]" | wc > 0 0 0 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r4[0-9]" | wc > 25 775 5190 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r5[0-9]" | wc > 55 985 6265 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r6[0-9]" | wc > 152 2396 17011 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r7[0-9]" | wc > 24 828 5747 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r8[0-9]" | wc > 0 0 0 > # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r9[0-9]" | wc > 20 740 5135 >=20 > WARNING: > That last means that clang is using some r's that > devel/powerpc64-gcc is not. >=20 > Is libgcc_s ready to deal with those extras that are > in the 90s? Is this an ABI difference between clang > (as configured) and powerpc64-gcc (as configured)? >=20 > Is there a problem based on powerpc64-gcc not generating > examples of those 90s "extras"? Is this lack of support > for some part of some ABI? clang is also using r with in the 10x's: # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r10[0-9]" | wc 45 315 2205 # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r[0-9][0-9][0-9]" | wc 45 315 2205 By contrast powerpc64-gcc is not: # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r[0-9][0-9][0-9]" | wc 0 0 0 =3D=3D=3D Mark Millard markmi at dsl-only.net