[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 #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #8)
> On Tue, 2 Nov 2021, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103006
> > 
> > --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> > Looks like that.
> > What do you think about unrolling making variable copies?  We'd need to be sure
> > that the scope of the variable is the loop we are unrolling though (or
> > something nested in it).
> 
> Being able to determine that would solve the very issue we're trying
> to fix with making the copy.  The problem is that we put in CLOBBERs
> based on the original BINDs but later optimizers do not respect the
> birth boundary.  If we can figure that out we could ignore the
> respective CLOBBERs for the CFG expansion live compute as well.
> 
> I think we may be able to compute the CFG SCC a CLOBBER resides in
> and in case the CLOBBERed variable is live-in into that SCC we cannot
> prune it with that CLOBBER.  Or so.

Tried that but while it solves PR97821 it doesn't fix the case in this bug
because there the CLOBBER that breaks things is not inside a SCC but the
issue in this case is that not all accesses to 'h' also mention h and thus
we miss to make 'h' live again after the CLOBBER.

I also fear the more variables we expose the easier it will be to run into
this issue.

It might be possible to (conservatively) track pointers from ADDR_EXPR
mentions, but that's going to give up in most of the interesting cases
(it has the same issue as ideas how to prevent "leakage" via pointers).

The other idea that we discussed past in time is to perform stack slot sharing
early when the CLOBBERs are still OK to use.  Possibly even w/o CLOBBERs
but with the GIMPLE binds we have even after gimplifying.  We'd make the
"stack slot" sharing explicit by replacing decls assigned to the same
stack slot with either the larges of the decls or anonymous stack memory
(a new decl).  Doing this before inlining is complete will obviously not
catch all important cases.  Doing it after inlining requires being careful
during early optimizations (jump threading is the one transform we do early
that can cause code duplication and followup CSE).