https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77485
--- Comment #6 from Jeffrey A. Law <law at redhat dot com> ---
So DSE involving CONSTRUCTOR nodes is a bit of a pain.
The way CONSTRUCTOR nodes are used past gimplification is awkward for DSE.
Specifically we have a CONSTRUCTOR node with no ELTS. The semantics of that
are the entire object is zero initialized. In fact, unless a magic flag is
set, any field not showing up in CONSTRUCTOR_ELTS is to be zero initialized.
So while we can easily identify elements from the CONSTRUCTOR that are dead,
it's not just a matter of walking the CONSTRUCTOR_ELTs and removing those which
are dead. Instead we'd have to add a suitable field for every element of the
object which is not dead. Ugh.
Given the usage and semantics, we could treat a CONSTRUCTOR node (after
verification) as a memset. That would allow the code I've already written
which can chop off the head or tail of a memset to be re-used to simplify
CONSTRUCTORS. Note that my prototype actually turns the CONSTRUCTOR into a
memset. At that point we bypass all that code in expr.c to find a reasonably
efficient way to expand the CONSTRUCTOR node and instead go through the paths
to try to emit an efficient memset.
For the given test we take this:
basic block 2, loop depth 0
pred: ENTRY
# .MEM_2 = VDEF <.MEM_1(D)>
<retval> = {};
# .MEM_3 = VDEF <.MEM_2>
<retval>.buf[0] = 48;
# .MEM_4 = VDEF <.MEM_3>
<retval>.buf[1] = 32;
[ ... ]
# VUSE <.MEM_33>
return <retval>;
succ: EXIT
Note the CONSTRUCTOR assignment to retval. We turn that into:
basic block 2, loop depth 0
pred: ENTRY
# VUSE <.MEM>
_34 = MEM[(struct FixBuf *)&<retval> + 31B];
# .MEM_2 = VDEF <.MEM_1(D)>
__builtin_memset (_34, 0, 169);
# .MEM_3 = VDEF <.MEM_2>
<retval>.buf[0] = 48;
# .MEM_4 = VDEF <.MEM_3>
<retval>.buf[1] = 32;
[ ... ]
# VUSE <.MEM_33>
return <retval>;
succ: EXIT
Note how the CONSTRUCTOR initialization has been replaced by a memset which
starts at offset 31 from the start of the object and initialized 169 bytes.
Instrumentation shows that handling CONSTRUCTORS in terms of static
opportunities to improve the code is more beneficial than any of the other
things we've looked at within the context of bz33562. But it's also by far
the ugliest of the transformations.
