From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5537B385802B; Mon, 1 Aug 2022 22:43:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5537B385802B From: "kloczko.tomasz at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/106499] LTO runs forever in libfabric 1.15.1 linking Date: Mon, 01 Aug 2022 22:43:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: unknown X-Bugzilla-Keywords: compile-time-hog, memory-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: kloczko.tomasz at gmail dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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: Mon, 01 Aug 2022 22:43:07 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106499 --- Comment #9 from Tomasz K=C5=82oczko -= -- (In reply to Andrew Pinski from comment #8) [..] > Basically with the flatten attribute and lto, every function needs to the= re > and cloned and inlined causing a lot of memory and time really. > Functions become huge and all. Gcc memory usage for some things can be > improved but it won't be enough. Knowing size of the non-LTO optimised DSO I suppose that sill it maybe some design issue (higher level) which is causing that inline operations are cau= sing such gigantic memory usage increase. And/or maybe it would be good to organise some internal metric with such operation counter to display at least some warning that some threshold of s= uch operations has been reached? Maybe I'm mumbling but I'm trying to find at least sone generic solution to have some at least linker fart that thing are going in wrong direction beca= use what is implemented in the code ..=