Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Jun 2018 12:38:19 -0700
From:      Mark Millard <>
Subject:   Re: svn commit: r334702 - head/sys/sys
Message-ID:  <>

Next in thread | Raw E-Mail | Index | Archive | Help
Jonathan T. Looney jtl at 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
( went
away in early 2018-Mar)

Want to link to this message? Use this URL: <>