https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
Even before IVOPTs we have an access to in[] "after" the clobber. I think the
fact that there are multiple instances of in is not well represented and
for the testcase at hand jump-threading essentially exposes two instances
of in[] with the second being live across a backedge (DOM rotates the loop),
crossing liveness with the instance live on loop entry.
I believe in this situation even simple CSE can wreck our liveness analysis
if you'd consider
addr1 = ∈
in ={v} CLOBBER;
addr2 = ∈
...
where the address might be easily exposed in a testcase and the CSE triggering
after some unrolling.
Ideas to do stack-slot sharing very early and expose it in the IL will
have quite an impact throughout the compilation and would not allow
sharing of stack slots only exposed after inlining for example (to be
reliable the stack slot sharing would need to happen as early as
gimple lowering where we remove BINDs and make all variables function-scope).
