On Sat, 3 Feb 2018, Conrad Meyer wrote:
On Sat, Feb 3, 2018 at 3:52 AM, Bruce Evans <b...@optusnet.com.au> wrote:
On Fri, 2 Feb 2018 a bug that doesn't want repl...@freebsd.org wrote:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225626
--- Comment #1 from Brooks Davis <bro...@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
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
