https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Shouldn't dse_optimize_redundant_stores be at least a little bit more
aggressive?
I mean on:
struct S { int a; char b; char c; char d; };
void foo (struct S);
void bar (void) { struct S s = {}; s.a = 0; s.b = 0; s.c = 0; s.d = 0; foo (s);
}
dse1 removes s.a = 0; but keeps the rest, dse2 removes s.b = 0; but keeps the
rest, dse3 removes s.c = 0; but still keeps s.d = 0; and only store-merging in
this case optimizes it, while e.g. in GCC 6 or 8 fre1 optimized this (GCC 9
fre1 no longer does).
So, rather than just walking immediate uses of the vdef, can't it under some
small limit keep walking the vdef-vuse chains, skip loads/stores that cannot
alias it, and when removing a redundant store keep looking after it (or, even
when not removing, such as s.a = 3; above, keep looking for stores to bytes
that don't overlap already non-zero ones)?
Or is it better to readd it in FRE after fixing whatever bugs it had that lead
to the removal?
