From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C48653857B89; Mon, 1 Aug 2022 22:56:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C48653857B89 From: "pinskia at gcc dot gnu.org" 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:56: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: pinskia at gcc dot gnu.org 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:56:07 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106499 --- Comment #10 from Andrew Pinski --- (In reply to Tomasz K=C5=82oczko from comment #9) > (In reply to Andrew Pinski from comment #8) > [..] > > Basically with the flatten attribute and lto, every function needs to t= here > > 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. >=20 > Knowing size of the non-LTO optimised DSO I suppose that sill it maybe so= me > design issue (higher level) which is causing that inline operations are > causing 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 > such 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 > because what is implemented in the code .. The flatten attribute is designed to override all heuristics in the compiler that is designed to not cause the gignatic memory usage and compile time. Basically you told the compiler to ignore those.=