From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D09DC3858404; Fri, 23 Jun 2023 11:21:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D09DC3858404 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1687519267; bh=yVKVCx4RxBJ/Hbz1qDaR60o3R7w6uRF7BpvoBwjMWGg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hV7c7LMw+iKi8xJbMYY+tdwLAEGHOgy8Zs2zFOgP2TcyXzsW/p+LRGdHJdiwFmU9F dHsroZXqaIxvTxvHJTHlA6+V6m8YuyAlE1/Vg8ymTCJ3ekx+qOQmES1OZVX8OyGE/Q zneCkQlwol7pAOPXdsHwnCk59PVmkEXTLSHiuvYE= From: "rguenth 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 11:21:06 +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: rguenth 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 #7 from Richard Biener --- (In reply to Jan Hubicka from comment #6) > Comdats are really in conflict with the fact that we have command line > options. I blame C++ standard for that and I don't think there is fully > satisfactory solution to this problem. >=20 > 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 practi= ce. Really? :/ > 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. I think it would be desirable to diagnose these, maybe with an option to selectively disable this specific diagnostic. Because while it is not always a correctness issue it can be a performance issue as well. > 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 it 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 across all syntacit aliases. >=20 > Also that conditional that disables early inliner for all always_inlines = is > probably bit harmful these days as libstdc++ indeed has quite interesting > set of always_inlines that call normal inlines. I noticed that just recen= tly > while looking into the push_back implementation how complex maze it got. >=20 > I will fix early inliner to allow safe inlining to always_inlines. Beware of new always-inline calls then appearing after greedy inlining (though that's exactly the case that we try to avoid here). I suppose you could disable inlining of a function which contains always-inline calls or simply functions that did not yet have the early inliner run on them (so keep the current behavior in cycles). Beware of indirect always-inline calls then. Btw, for Skia the issue is really that some auto-generated CTOR isn't marked always-inline but everything else is. Maybe they should use flatten instead of always-inline ...=