https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120310
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> Guess one case is when tree DSE removes all stores to some automatic
> addressable variable, in that case it would be nice to populate debug stmts
> to all those removed locs and state what values it had there.
> Another case is where DSE keeps some stores to it and removes others.
> If it removes the last store before the var goes out of scope, perhaps
> adding debug stmt for that is fine too, but not sure what to do in case it
> removes a store because it is overwritten by a later store, say
> void qux (int *);
> void
> baz (void)
> {
> int a = 42;
> a = 43;
> qux (&a);
> }
> Because there dse1 does
> # DEBUG BEGIN_STMT
> - a = 42;
> # DEBUG BEGIN_STMT
> a = 43;
> and if we add # DEBUG a => 42 we'd need to add some debug stmt to say from
> this point on, value of a is in the a variable. Not sure if # DEBUG a => a
> would do it or if we'd need something else.
Since 'a' is still in memory we do not need any # DEBUG stmts for 'a', only
when there's a time where 'a' does not reflect the value in the abstract
machine - like for example when applying loop store motion, then inside
the loop we'd technically need debug stmts. Of course I have no idea
how that will work in the end on the consumer side.
So for the original DSE issue:
a = 1; <-- DSEd
...
a = 2; <-- kept
# DEBUG a = 1
...
a = 2;
do we correctly track stores to 'a' here and get correct location lists?
IIRC the patched from Richard S. simply kept the stores?
