From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 609D1385DC12; Thu, 9 Apr 2020 19:21:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 609D1385DC12 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1586460106; bh=kFviNOVqwig5iPW/ZpLN8Twb7I1Ht9qDKPTBGdHx/pk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DD+expX0BD4zYyq3bSGt7OkcRkbLSfviDPfVpRBYBwzb31dDBDibpPmBHcAY5VvXs YoNX5r6QJ5c/q333XHYV/wkDlmZG4zMSDTMmclTF2fumCTJV9A5pvT4cDnPpi+uECw BCNdzJrJxza92s6aMbRXsBEBffJW9GJygwbT3QvY= From: "cvs-commit 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: Thu, 09 Apr 2020 19:21:46 +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: cvs-commit 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: 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: Thu, 09 Apr 2020 19:21:46 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94495 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:33c45e51b4914008064d9b77f2c1fc0eea1ad060 commit r10-7665-g33c45e51b4914008064d9b77f2c1fc0eea1ad060 Author: Jakub Jelinek Date: Thu Apr 9 21:21:24 2020 +0200 cselib, var-tracking: Improve debug info after the cselib sp tracking changes [PR94495] On the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94495#c5 testcase GCC emits worse debug info after the PR92264 cselib.c changes. The difference at -O2 -g -dA in the assembly is (when ignoring debug in= fo): # DEBUG g =3D> [argp] # DEBUG k =3D> [argp+0x20] # DEBUG j =3D> [argp+0x18] # DEBUG a =3D> di # DEBUG b =3D> si # DEBUG c =3D> dx # DEBUG d =3D> cx # DEBUG h =3D> [argp+0x8] # DEBUG e =3D> r8 # DEBUG i =3D> [argp+0x10] # DEBUG f =3D> r9 ... .LVL4: + # DEBUG h =3D> [sp+0x10] + # DEBUG i =3D> [sp+0x18] + # DEBUG j =3D> [sp+0x20] + # DEBUG k =3D> [sp+0x28] # DEBUG c =3D> entry_value # SUCC: EXIT [always] count:1073741824 (estimated locally) ret .LVL5: + # DEBUG k =3D> [argp+0x20] # DEBUG a =3D> bx # DEBUG b =3D> si # DEBUG c =3D> dx # DEBUG d =3D> cx # DEBUG e =3D> r8 # DEBUG f =3D> r9 + # DEBUG h =3D> [argp+0x8] + # DEBUG i =3D> [argp+0x10] + # DEBUG j =3D> [argp+0x18] This means that before the changes, h, i, j, k could be all expressed in DW_AT_location directly with DW_OP_fbreg , but now we n= eed to use a location list, where in the first part of the function and last part of the function (everything except the ret instruction) we use that DW_OP_fbreg , but for the single ret instruction we instead say those values live in something pointed by stack pointer + offset. It is true, but only because stack pointer + offset is equal to DW_OP_f= breg at that point. The var-tracking pass has for !frame_pointer_needed functions code to canonicalize stack pointer uses in the insns before it hands it over to cselib to cfa_base_rtx + offset depending on the stack depth at each point. The problem is that on the last epilogue pop insn (the one right before ret) the canonicalization is sp =3D argp - 8 and add_stores reco= rds a MO_VAL_SET operation for that argp - 8 value (which is the SP_DERIVED_VALUE_P VALUE the cselib changes canonicalize sp based acces= ses on) and thus var-tracking from that point onwards tracks that that VALUE (2:2) now lives in sp. At the end of function it of course needs to fo= rget it again (or it would need on any changes to sp). But when processing that uop, we note that the VALUE has changed and anything based on it changed too, so emit changes for everything. Before that var-tracking itself doesn't track it in any register, so uses cselib and cselib knows through the permanent equivs how to compute it using argp (i.e. what will be DW_OP_fbreg). The following fix has two parts. One is it detects if cselib can compu= te a certain VALUE using the cfa_base_rtx and for such VALUEs doesn't add the MO_VAL_SET operation, as it is better to express them using cfa_base_rtx rather than temporarily through something else. And the other is make = sure we reuse in !frame_pointer_needed the single SP_DERIVED_VALUE_P VALUE in other extended basic blocks too (and other VALUEs) too. This can be do= ne because we have computed the stack depths at the start of each basic bl= ock in vt_stack_adjustments and while cselib_reset_table is called at the e= nd of each extended bb, which throws away all hard registers (but the magic cfa_base_rtx) and so can hint cselib.c at the start of the ebb what VAL= UE the sp hard reg has. That means fewer VALUEs during var-tracking and m= ore importantly that they will all have the cfa_base_rtx + offset equivalen= cy. I have performed 4 bootstraps+regtests (x86_64-linux and i686-linux, each with this patch (that is the new cselib + var-tracking variant) and once with that patch reverted as well as all other cselib.c changes from this month; once that bootstrapped, I've reapplied the cselib.c changes= and this patch and rebuilt cc1plus, so that the content is comparable, but built with the pre-Apr 2 cselib.c+var-tracking.c (that is the old cselib one)= ). Below are readelf -WS cc1plus | grep debug_ filtered to only have debug sections whose size actually changed, followed by dwlocstat results on cc1plus. This shows that there was about 3% shrink in those .debug* sections for 32-bit and 1% shrink for 64-bit, with minor variable cover= age changes one or the other way that are IMHO insignificant. 32-bit old cselib [33] .debug_info PROGBITS 00000000 29139c0 710e5fa 00 = 0 0 1 [34] .debug_abbrev PROGBITS 00000000 9a21fba 21ad6d 00 = 0=20 0 1 [35] .debug_line PROGBITS 00000000 9c3cd27 1a05e56 00 = 0 0 1 [36] .debug_str PROGBITS 00000000 b642b7d 7cad09 01 MS= 0=20 0 1 [37] .debug_loc PROGBITS 00000000 be0d886 5792627 00 = 0 0 1 [38] .debug_ranges PROGBITS 00000000 1159fead e57218 00 = 0 0 1 sum 263075589B 32-bit new cselib + var-tracking [33] .debug_info PROGBITS 00000000 29129c0 71065d1 00 = 0 0 1 [34] .debug_abbrev PROGBITS 00000000 9a18f91 21af28 00 = 0=20 0 1 [35] .debug_line PROGBITS 00000000 9c33eb9 195dffc 00 = 0 0 1 [36] .debug_str PROGBITS 00000000 b591eb5 7cace0 01 MS= 0=20 0 1 [37] .debug_loc PROGBITS 00000000 bd5cb95 50185bf 00 = 0 0 1 [38] .debug_ranges PROGBITS 00000000 10d75154 e57068 00 = 0 0 1 sum 254515196B (8560393B smaller) 64-bit old cselib [33] .debug_info PROGBITS 0000000000000000 25e64b0 84d7c= c9 00 0 0 1 [34] .debug_abbrev PROGBITS 0000000000000000 aabe179 225e2= d 00 0 0 1 [35] .debug_line PROGBITS 0000000000000000 ace3fa6 19a35= 05 00 0 0 1 [37] .debug_loc PROGBITS 0000000000000000 ce6e960 89707= bc 00 0 0 1 [38] .debug_ranges PROGBITS 0000000000000000 157df11c 1c59= a70 00 0 0 1 sum 342274599B 64-bit new cselib + var-tracking [33] .debug_info PROGBITS 0000000000000000 25e64b0 84d8e= 86 00 0 0 1 [34] .debug_abbrev PROGBITS 0000000000000000 aabf336 225e8= d 00 0 0 1 [35] .debug_line PROGBITS 0000000000000000 ace51c3 199de= d5 00 0 0 1 [37] .debug_loc PROGBITS 0000000000000000 ce6a54d 85f62= da 00 0 0 1 [38] .debug_ranges PROGBITS 0000000000000000 15460827 1c59= a20 00 0 0 1 sum 338610402B (3664197B smaller) 32-bit old cselib cov% samples cumul 0..10 1231599/48% 1231599/48% 11..20 31017/1% 1262616/49% 21..30 36495/1% 1299111/51% 31..40 35846/1% 1334957/52% 41..50 47179/1% 1382136/54% 51..60 41203/1% 1423339/56% 61..70 65504/2% 1488843/58% 71..80 59656/2% 1548499/61% 81..90 104399/4% 1652898/65% 91..100 882231/34% 2535129/100% 32-bit new cselib + var-tracking cov% samples cumul 0..10 1230542/48% 1230542/48% 11..20 30385/1% 1260927/49% 21..30 36393/1% 1297320/51% 31..40 36053/1% 1333373/52% 41..50 47670/1% 1381043/54% 51..60 41599/1% 1422642/56% 61..70 65902/2% 1488544/58% 71..80 59911/2% 1548455/61% 81..90 104607/4% 1653062/65% 91..100 882067/34% 2535129/100% 64-bit old cselib cov% samples cumul 0..10 1233211/48% 1233211/48% 11..20 31120/1% 1264331/49% 21..30 39230/1% 1303561/51% 31..40 38887/1% 1342448/52% 41..50 47519/1% 1389967/54% 51..60 45264/1% 1435231/56% 61..70 69431/2% 1504662/59% 71..80 62114/2% 1566776/61% 81..90 104587/4% 1671363/65% 91..100 876085/34% 2547448/100% 64-bit new cselib + var-tracking cov% samples cumul 0..10 1233471/48% 1233471/48% 11..20 31093/1% 1264564/49% 21..30 39217/1% 1303781/51% 31..40 38851/1% 1342632/52% 41..50 47488/1% 1390120/54% 51..60 45224/1% 1435344/56% 61..70 69409/2% 1504753/59% 71..80 62140/2% 1566893/61% 81..90 104616/4% 1671509/65% 91..100 875939/34% 2547448/100% 2020-04-09 Jakub Jelinek PR debug/94495 * cselib.h (cselib_record_sp_cfa_base_equiv, cselib_sp_derived_value_p): Declare. * cselib.c (cselib_record_sp_cfa_base_equiv, cselib_sp_derived_value_p): New functions. * var-tracking.c (add_stores): Don't record MO_VAL_SET for cselib_sp_derived_value_p values. (vt_initialize): Call cselib_record_sp_cfa_base_equiv at the start of extended basic blocks other than the first one for !frame_pointer_needed functions.=