Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?E17B30CA-F19D-4875-BA62-386F57730CDA>