From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 158F03858D37; Fri, 23 Jun 2023 10:47:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 158F03858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1687517252; bh=zQBfX1tXXpw4LaEBlU+jxICaVjbdcAg4rjBRqJ05jSs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eo+4FB1dUOcZUZw3KqBZC/TY2Nwhx7s0/GNVJZpFgsZ2d0UAxPZm284xCh7SaKh8i CoJ4/hxVT8XD1ktbxzoJO8/xuJI6G6UhfyLgPM2ckn18gKTaigJ9ie8GyDaLgamblt 0nTlhr1jTs4tuqXPf9ztrnvLaJmPXVXWUgFkvP1A= From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming Date: Fri, 23 Jun 2023 10:47:30 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 13.1.1 X-Bugzilla-Keywords: lto, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.2 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110334 --- Comment #6 from Jan Hubicka --- Comdats are really in conflict with the fact that we have command line opti= ons. I blame C++ standard for that and I don't think there is fully satisfactory solution to this problem. I was playing with the idea of warning when at lto time when comdats have different command line options, but this triggers way too often in practice= . We would need to determine "dangerous" one i.e. when -fno-avx2 is replaced by -favx2 code.=20 There are many ways one can stubly change semantics of the IL which makes merging possibly dangerous which is done often in larger projects, like firefox. With syntactic aliases it is possible to keep multiple copies of comdat function through merging process so inlining will chose corresponding one, = but it does make other things harder. One important anoyance is that it makes i= t a lot harder to estimate overall size of the translation unit and how inlining affects it. We currently assume that every function will need offline unless all calls to it disappears. We will need to understand that this is true ac= ross all syntacit aliases. Also that conditional that disables early inliner for all always_inlines is probably bit harmful these days as libstdc++ indeed has quite interesting s= et of always_inlines that call normal inlines. I noticed that just recently wh= ile looking into the push_back implementation how complex maze it got. I will fix early inliner to allow safe inlining to always_inlines.=