Date: Mon, 3 Aug 2020 19:19:29 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Jessica Clarke <jrtc27@FreeBSD.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-projects@freebsd.org, Ed Schouten <ed@nuxi.nl>, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r363773 - projects/clang1100-import/contrib/llvm-project/compiler-rt/lib/builtins Message-ID: <227068EE-C71E-4CD1-8DE0-A1CF9363D2B2@FreeBSD.org> In-Reply-To: <F5954FB2-E301-4ADD-85AC-5CF1E4352EBF@freebsd.org> References: <202008021807.072I7GM9059504@repo.freebsd.org> <5D6813EB-F270-412D-8C15-8A05CB6353DE@freebsd.org> <B0A89ACC-99D6-4329-8FC9-135A953262E4@FreeBSD.org> <F5954FB2-E301-4ADD-85AC-5CF1E4352EBF@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_5769641E-6573-4294-A0B0-FA5E655EA6B5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 3 Aug 2020, at 19:05, Jessica Clarke <jrtc27@FreeBSD.org> wrote: > > On 3 Aug 2020, at 17:50, Dimitry Andric <dim@FreeBSD.org> wrote: >> >> On 2 Aug 2020, at 22:50, Jessica Clarke <jrtc27@FreeBSD.org> wrote: ... >> 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? > > I don't think it matters much. __clzdi2 is this (the preprocessed > version of which you provided): > > dwords x; > x.all = a; > const si_int f = -(x.s.high == 0); > return __builtin_clz((x.s.high & ~f) | (x.s.low & f)) + > (f & ((si_int)(sizeof(si_int) * CHAR_BIT))); > > The implementation of __clzsi2 does a bunch more work than that (not > crazy, but still several times more), so I don't think you'll notice > all that much. Besides, Clang is our primary compiler and won't suffer > from this workaround, so I personally have no qualms about a small > performance hit when using GCC and what should be a relatively cold[1] > function. I'm of the view we should be as close to upstream as > possible, ideally with zero diffs, so personally wouldn't carry patches > like this unless it had a noticeable affect on system performance, but > even then would encourage others to patch it upstream first and > foremost. Yeah, less patches is always OK, so I'll drop this particular one, then. Thanks for the feedback! -Dimitry --Apple-Mail=_5769641E-6573-4294-A0B0-FA5E655EA6B5 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCXyhHIQAKCRCwXqMKLiCW o7aDAJ4++R0t+c59UHKfqosUN1IaQe1uAACfZHA0jFwXBuRmip0D9RzTcqbTCJc= =e5R1 -----END PGP SIGNATURE----- --Apple-Mail=_5769641E-6573-4294-A0B0-FA5E655EA6B5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?227068EE-C71E-4CD1-8DE0-A1CF9363D2B2>