From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 67961385C401; Wed, 24 Aug 2022 16:42:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 67961385C401 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1661359329; bh=a/2zB0Bkkt2V548y0kKdr8wP9P4Ypm6jpH9SV7ea/z4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=k4QOlUoEOZsdqV7lA/2q3T+R1TbRf5H4TW0HzFberqUhyrkB3gVZzsChkKbpagGX3 Av3Jn4DsF/m23n4KNr05c7GZWM8rgulcsae7zi9ODeWGWqGB0Fqeg3gr+6zJojad5j eVQjyy4GAgfnxI72b7yrUZ1u/TxrEANF3cXXFKjk= From: "dthorn at google dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/106725] LTO semantics for __attribute__((leaf)) Date: Wed, 24 Aug 2022 16:42:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 12.2.0 X-Bugzilla-Keywords: documentation, lto X-Bugzilla-Severity: normal X-Bugzilla-Who: dthorn at google dot com 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: --- 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=3D106725 --- Comment #2 from Daniel Thornburgh --- (In reply to Richard Biener from comment #1) > If GCC, with LTO, would partition the program into two LTRANS partitions, > one containing main and bar and one containing foo then applying this > optimization promise during LTRANS time on the main/bar partition would > be wrong as you say - but I think GCC doesn't do this. In this case, foo() was already compiled to native code outside of LTO. Wouldn't this then mean that its contents wouldn't be available for the WPA= and LTRANS phases of the LTO code generation? It seems like the compiler wouldn= 't know that foo() might call bar(), and the presence of `__attribute__((leaf)= )` would cause it to assume that it doesn't call bar().=