[Bug debug/94495] [10 Regression] Debug info size growth since r10-7515-g2c0fa3ecf70d199a

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

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu.org,
                   |                            |law at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems I forgot most of how var-tracking.c works :(

Before the return we have two pop instructions and the second one increments
the stack pointer to the value it had at the start of the function.

For the pop, add_stores is called on loc (reg sp) and expr (set (reg sp) (plus
(reg argp) (const_int -8))).
Now, before my cselib.c sp derived value changes, the cselib lookup of the sp
value at that point was a fresh VALUE that wasn't really used by much, but with
those changes cselib returns back the SP_DERIVED_VALUE_P which is used very
often and has cfa_base_val - 8 as one of its locations.
Now, when processing the MO_VAL_SET created by that add_store, the VALUE is
marked as changed (hey, we have a nice location for this VALUE - %rsp!) and
everything that is related to that VALUE is marked as changed too and gets new
notes emitted.
Except that the %rsp location isn't really a good location when we can express
it as argp + constant, (where argp is the cfa value), because then it is
something we express using DW_OP_fbreg and it can stay that way through the
whole function.
So it isn't beneficial to change all VALUEs/decls that are related to that
VALUE when it for a few instruction is live in the stack pointer.
I thought var-tracking has code to analyze if the cur_loc isn't usable anymore
and only change cur_loc if it isn't usable, but it seems it doesn't; this
SP_DERIVED_VALUE_P has cur_loc NULL all the way until the pop in the epilogue,
before that we instead query cselib for the location and find that way the
cfa_base_rtx + constant.
So, shall var-tracking itself (other than the vt_initialize phase that does
that already) special case the cselib_sp_based_value_p VALUEs if they can be
expressed as cfa_base_rtx or cfa_base_rtx + constant somehow and ignore any
changes to them?  Or shall what vt_initialize calls special case those?

Alex, any insights on this?