[Bug rtl-optimization/103006] [9/10/11/12 Regression] wrong code at -O1 or -O2 on x86_64-linux-gnu by r7-7101

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103006

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Oh, and I think address-takens are really not an issue but the accesses based
on them which confuse the simplistic live analysis to not recognize those as
births.

So we _can_ introduce explicit birth operations.  The simplest thing we
probably
can do is to add clobbers there and set a special 'birth' flag on them
just for liveness analysis, the rest of the compiler can treat them like
clobbers - besides cases where we remove clobbers.  We can't remove a birth
without also removing all clobbers of a variable (even in copies of birth-death
regions).  It might be tempting to somehow link birth and its clobbers (IIRC
with cleanups and
so we can have multiple clobbers for one birth), like via SSA def and uses, but
when we copy a birth that breaks down.  So the alternative is probably to
mark a variable as not to be subject to stack slot sharing when removing a
birth clobber.

The initial birth clobber would be at a more conservative position than
the current way of treating the first mention as birth but we can sink
birth clobbers (even across address takens) and hoist clobbers to shrink
live ranges at some point.

Both birth and clobber act as optimization barrier for loads and stores
of the affected variable, that's good for the purpose but possibly bad
for optimization.  I checked and for example loop store motion does consider
clobbers inside a loop as reason to not optimize.

And with the current scheme we don't even optimize cases like

struct Foo { int i; int j; int a[24]; };

void bar(struct Foo f);

void baz()
{
  struct Foo f, g;
  f.i = 1;
  bar (f);
  g.j = 2;
  bar (g);
}

as nothing hoists the clobbers we only put at the end of the function and
thus f and g appear to conflict (we only use clobbers to compute live,
for not address taken vars we could rely on mentions only).

I don't think we can reasonably fix all of the issue on branches and I
have my doubts for GCC 12.