Date: Thu, 7 Jun 2018 12:38:19 -0700 From: Mark Millard <marklmi26-fbsd@yahoo.com> To: jtl@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r334702 - head/sys/sys Message-ID: <E17B30CA-F19D-4875-BA62-386F57730CDA@yahoo.com>
next in thread | raw e-mail | index | archive | help
Jonathan T. Looney jtl at freebsd.org wrote on
Thu Jun 7 03:00:00 UTC 2018 :
> I believe the theory is that the compiler (remember, this is
> __builtin_memset) can optimize away portions of the zeroing, or can
> optimize zeroing for small sizes.
>
> For example, imagine you do this:
>
> struct foo {
> uint32_t a;
> uint32_t b;
> };
>
> struct foo *
> alloc_foo(void)
> {
> struct foo *rv;
>
> rv = malloc(sizeof(*rv), M_TMP, M_WAITOK|M_ZERO);
> rv->a = 1;
> rv->b = 2;
> return (rv);
> }
>
> In theory, the compiler can be smart enough to know that the entire
> structure is initialized, so it is not necessary to zero it.
>
> (I personally have not tested how well this works in practice. However,
> this change theoretically lets the compiler be smarter and optimize away
> unneeded work.)
>
> At minimum, it should let the compiler replace calls to memset() (and the
> loops there) with optimal instructions to zero the exact amount of memory
> that needs to be initialized. (Again, I haven't personally tested how smart
> the compilers we use are about producing optimal code in this situation.)
Change struct foo to something like (just a specific
illustration of a more general type of context):
struct foo {
uint16_t a;
// assume padding in the struct
uint32_t b;
};
Are the compilers well behaved about always initializing the
padding (if any) to zero when the __builtin_memset is used to
implement M_ZERO but the compiler is optimizing what is actually
zeroed based on what was initialized explicitly?
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E17B30CA-F19D-4875-BA62-386F57730CDA>