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)
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
