https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 6 Dec 2016, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 > > --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > If -Og does not force user variables/parameters to stack nor forces an > artificial use of the var at the end of their scope, then it will always > happen, the rest is purely best effort, see if the var value can be computed > from something else and punt if it can't. The problem is mainly register > allocation, if the var is seen by RA as dead after certain point, then the RA > doesn't try to keep it alive in some register or memory. > In particular on this testcase, DW_OP_GNU_entry_value is emitted (as last > resort) for the count variable, and similarly for argc in main (again, it > isn't > used after the function call). > So, in this particular case it might help if glibc tried to provide better > debug info for __libc_start_main and/or _start (if the argc and/or argv values > can be easily computed; though, e.g. computing argc from argv array might not > be correct, because main could have changed it). > For the potential -Og change to be more useful, it would mean adding some > artificial stmts at the end of scope of user vars (e.g. where we poison vars > for -fsanitize-user-after-scope) that would not expand into a real assembly > insn(s), but something like (use (var)) and would convince the RA to keep them > alive somewhere. I guess that wouldn't stop at calls but if we want to avoid <optimized out> for locals we could add artificial uses for all vars where they go out of scope... Sth orthogonal to -Og, -fkeep-vars-live=N with some level, default to N > 0 for -Og maybe. Of course it will likely pessimize code as I don't see how we can easily compute whether var-tracking might reverse compute a vars value from sth else.
