Optimize initialization of small padded objects

When small objects containing padding bits (or bytes) are fully
initialized, we will often store them in registers, and setting
bitfields and other small fields will attempt to preserve the
uninitialized padding bits, which tends to be expensive.
Zero-initializing registers, OTOH, tends to be cheap.

So, if we're optimizing, zero-initialize such small padded objects
even if that's not needed for correctness.  We can't zero-initialize
all such padding objects, though: if there's no padding whatsoever,
and all fields are initialized with nonzero, the zero initialization
would be flagged as dead.  That's why we introduce machinery to detect
whether objects have padding bits.  I considered distinguishing
between bitfields, units and larger padding elements, but I didn't
pursue that distinction.

Since the object's zero-initialization subsumes fields'
zero-initialization, the empty string test in builtin-snprintf-6.c's
test_assign_aggregate would regress without the addition of
native_encode_constructor.


for  gcc/ChangeLog

	* expr.cc (categorize_ctor_elements_1): Change p_complete to
	int, to distinguish complete initialization in presence or
	absence of uninitialized padding bits.
	(categorize_ctor_elements): Likewise.  Adjust all callers...
	* expr.h (categorize_ctor_elements): ... and declaration.
	(type_has_padding_at_level_p): New.
	* gimple-fold.cc (type_has_padding_at_level_p): New.
	* fold-const.cc (native_encode_constructor): New.
	(native_encode_expr): Call it.
	* gimplify.cc (gimplify_init_constructor): Clear small
	non-addressable non-volatile objects with padding or
	other uninitialized fields as an optimization.

for  gcc/testsuite/ChangeLog

	* gcc.dg/init-pad-1.c: New.

0 files changed, 0 insertions, 0 deletions