Date: Sun, 4 Feb 2018 15:07:10 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Conrad Meyer <cem@freebsd.org> Cc: Bruce Evans <brde@optusnet.com.au>, freebsd-bugs@freebsd.org, Brooks Davis <brooks@freebsd.org> Subject: Re: [Bug 225626] r325865 malloc vs bzero Message-ID: <20180204142826.B909@besplex.bde.org> In-Reply-To: <CAG6CVpXxb21wZqLcspJLm%2BanJdgfV-EKhTjB1-x2rNWBMrJKBg@mail.gmail.com> References: <bug-225626-8@https.bugs.freebsd.org/bugzilla/> <bug-225626-8-RsDlqNTq6z@https.bugs.freebsd.org/bugzilla/> <20180203215302.T1064@besplex.bde.org> <CAG6CVpXxb21wZqLcspJLm%2BanJdgfV-EKhTjB1-x2rNWBMrJKBg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 3 Feb 2018, Conrad Meyer wrote: > On Sat, Feb 3, 2018 at 3:52 AM, Bruce Evans <brde@optusnet.com.au> wrote: >> On Fri, 2 Feb 2018 a bug that doesn't want replies@freebsd.org wrote: >> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225626 >>> >>> --- Comment #1 from Brooks Davis <brooks@FreeBSD.org> --- >> ... >>> Note that memset should be used in preference to bzero as the compiler >>> should >>> be able to elide most of the cost of the memset since it can emit it >>> inline and >>> then delete the dead stores. > > (To Brooks:) > Not in -ffreestanding by default, unfortunately. We can give it that > hint back by defining memset() in terms of __builtin_memset(), though. > We have done so for some sizes of constant bzero(), but not for bcopy, > memcpy, or memmove, unfortunately. > >> Note that memset() should _not_ be used in preference to bzero() since: >> - using memset() in the kernel is a style bug, except possibly with a >> nonzero >> fill byte >> - the existence of memset() in the kernel is an umplementation style bug, >> except possibly with a nonzero fill byte. > > This is total nonsense. This is total sense. memset() was intentionally left out until someone broke this. >> ... >> - using memset() instead of bzero() in the kernel is a pessimization. Since >> memset() is only compatibilty cruft and should not be used, it is >> intentionally not as optimized as bzero(). >> ... > > This can and should be fixed. That would reward using the style bug. >> Not so simlarly for memcpy(). Its use in the kernel is now just a style >> bug, since the compiler is not allowed to inline it (except in my version >> of course). > > This should be fixed. Yes, it is easier to fix (by removing it) than for memset(), because it has no functionality that is not in bcopy(). My version actually translates memset() with fill byte 0 to bzero() and then bzero with compile-time-constant size <= 32 to __builtin_memset(). It doesn't remove memcpy(), but translates it to __builtin_memcpy() for all sizes. memcmp() is another pessimized KPI. When memset() and memcmp() were first misimplemented in the kernel, memcmp() was broken. It called bcmp(), but bcmp() returns 2 states while memcmp() returns 3 states. memcmp(9) now uses the fairly slow generic C version from libc/string. bcmp(9) on x86 has always been misoveroptimized. It is rarely used, so its efficiency is unimportant, so it shouldn't be MD, and the x86 version of it is only optimized for the original i386 (or maybe the 8088 with 32-bit extensions). So the pessimization doesn't matter. >> ... >> FreeBSD was changed to use -ffreestanding because without it the compiler >> is allowed to inline functions like printf() and gcc started doing that >> (it converts printf(3) into puts() galore, and puts() doesn't exist in >> the kernel). This broke all inlining, but no one cared (except me of >> course). > > Isn't the other issue that non-freestanding links libgcc (GPL) into > the kernel? We could work around puts() by adding a puts() > implementation, of course. No, the kernel never used libgcc. The kernel always used libkern, which must contain all the libgcc functions that are actually used (not many, and none of the more complicated FP ones. The main complicated one is 64-bit division on 32-bit arches (__[u]divdi3())). Also, I think we didn't care about (GPL2?) libgcc in the kernel any more than in applications. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180204142826.B909>