From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6E6A739450FE; Wed, 8 Apr 2020 15:25:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6E6A739450FE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1586359533; bh=lXx6fw+2IT6oS8X0vAsCVw7ibOXaJqqyG/8AydQyojc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=yqA0s7B8azjPkFFCLzvFVEJl5ZkGR3/qJ8gy9/kouhIUoiJZGwknuBzxBxZTqO0lp DV5hbWQ0U9nViC6CCWd0cX3LIxYtt65UvGusRywYoeKv71iK8ZsJ17WcHnxWfM8Z/c xsnYCtQyWRKsclAVhYl1bS2bCLoEr1gyNSilRlE4= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/94495] [10 Regression] Debug info size growth since r10-7515-g2c0fa3ecf70d199a Date: Wed, 08 Apr 2020 15:25:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 15:25:33 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94495 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aoliva at gcc dot gnu.org, | |law at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- 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) (p= lus (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 expr= ess 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 anym= ore 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 epilog= ue, 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?=