From owner-svn-src-projects@freebsd.org Mon Aug 3 16:50:30 2020 Return-Path: Delivered-To: svn-src-projects@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3AE4B37FE67 for ; Mon, 3 Aug 2020 16:50:30 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BL3m60nMKz45LD; Mon, 3 Aug 2020 16:50:30 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id C0DCD2AD1D; Mon, 3 Aug 2020 16:50:29 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::704a:83ae:3b05:45f6] (unknown [IPv6:2001:470:7a58:0:704a:83ae:3b05:45f6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 912272323; Mon, 3 Aug 2020 18:50:27 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C4638C7A-B292-4A67-BF3C-14490DDF8A5C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: svn commit: r363773 - projects/clang1100-import/contrib/llvm-project/compiler-rt/lib/builtins Date: Mon, 3 Aug 2020 18:50:20 +0200 In-Reply-To: <5D6813EB-F270-412D-8C15-8A05CB6353DE@freebsd.org> Cc: src-committers , svn-src-projects@freebsd.org, Ed Schouten , John Baldwin To: Jessica Clarke References: <202008021807.072I7GM9059504@repo.freebsd.org> <5D6813EB-F270-412D-8C15-8A05CB6353DE@freebsd.org> X-Mailer: Apple Mail (2.3445.104.15) X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 16:50:30 -0000 --Apple-Mail=_C4638C7A-B292-4A67-BF3C-14490DDF8A5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2 Aug 2020, at 22:50, Jessica Clarke wrote: >=20 > On 2 Aug 2020, at 19:07, Dimitry Andric wrote: >>=20 >> Author: dim >> Date: Sun Aug 2 18:07:16 2020 >> New Revision: 363773 >> URL: https://svnweb.freebsd.org/changeset/base/363773 >>=20 >> Log: >> Reapply r230021, r276851 and a few other commits to compiler-rt >>=20 >> Reapply r230021 (by ed): >>=20 >> Add a workaround to prevent endless recursion in compiler-rt. >>=20 >> SPARC and MIPS CPUs don't have special instructions to count >> leading/trailing zeroes. The compiler-rt library provides fallback >> rountines for these. The 64-bit routines, __clzdi2 and __ctzdi2, are >> implemented as simple wrappers around the compiler built-in >> __builtin_clz(), assuming these will expand to either 32-bit >> CPU instructions or calls to __clzsi2 and __ctzsi2. ... > Are you sure this is still necessary? https://reviews.llvm.org/D42902 > (which landed in in 2018 for 7.0.0, way after the original r230021 in > 2012) followed by a follow-up commit for the correct SPARC macro, = fixed > this in an OS-independent way upstream, but inside c?zdi2.c themselves > so you won't notice a merge conflict. Yes, you are probably right, though the preceding comment in int_lib.h specifically mentions: * Instead of placing this workaround in c?zdi2.c, put it in this * global header to prevent other C files from making the detour * through __c?zdi2() as well. There are indeed quite a lot of calls to __builtin_c[lt]z throughout compiler-rt, so removing this workaround from the int_lib.h header will possibly pessimize all of those. Is that going to work alright for all affected architectures, which appear to be mips64, riscv and sparc64? Note also that https://bugs.llvm.org/show_bug.cgi?id=3D11663 is *still* open, possibly because of that reason. But it looks like interest in the bug simply waned, and it was never closed. In any case, I managed to get the new-new-new-mk2-style version of mips64-xtoolchain working, and got these warnings, so indeed the fix is now applied in two places: /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/clzdi2.c:23: = warning: "__builtin_clz" redefined 23 | #define __builtin_clz(a) __clzsi2(a) | In file included from = /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/clzdi2.c:13: /usr/src/contrib/llvm-project/compiler-rt/lib/builtins/int_lib.h:112: = note: this is the location of the previous definition 112 | #define __builtin_clz __clzsi2 | The preprocessed C code looks OK, in the sense that it delegates to __clzsi2 now: extern si_int __clzsi2(si_int); si_int __clzdi2(di_int a) { dwords x; x.all =3D a; const si_int f =3D -(x.s.high =3D=3D 0); return __clzsi2((x.s.high & ~f) | (x.s.low & f)) + (f & ((si_int)(sizeof(si_int) * 8))); } And the resulting assembly shows no further external calls: 0000000000000000 <__clzdi2>: 0: 67bdffe0 daddiu sp,sp,-32 4: ffbf0018 sd ra,24(sp) 8: ffbc0010 sd gp,16(sp) c: ffb00008 sd s0,8(sp) 10: 3c1c0000 lui gp,0x0 14: 0399e02d daddu gp,gp,t9 18: 679c0000 daddiu gp,gp,0 1c: 0004103f dsra32 v0,a0,0x0 20: 2c430001 sltiu v1,v0,1 24: 0003802f dnegu s0,v1 28: 2463ffff addiu v1,v1,-1 2c: 00621824 and v1,v1,v0 30: 00042000 sll a0,a0,0x0 34: 00902024 and a0,a0,s0 38: df990000 ld t9,0(gp) 3c: 0320f809 jalr t9 40: 00642025 or a0,v1,a0 44: 32100020 andi s0,s0,0x20 48: 02021021 addu v0,s0,v0 4c: dfbf0018 ld ra,24(sp) 50: dfbc0010 ld gp,16(sp) 54: dfb00008 ld s0,8(sp) 58: 03e00008 jr ra 5c: 67bd0020 daddiu sp,sp,32 In summary, I'm fine with dropping this part of r230021, as long as everybody is convinced this does not pessimize the rest too much. -Dimitry --Apple-Mail=_C4638C7A-B292-4A67-BF3C-14490DDF8A5C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXyhATAAKCRCwXqMKLiCW oy2cAKDVudWLkMZkjQ+QsT/Ku5eqpvesYQCcCj8FzP4W9UcbCu58Iu8ZZl5dmY0= =lpMz -----END PGP SIGNATURE----- --Apple-Mail=_C4638C7A-B292-4A67-BF3C-14490DDF8A5C--