From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 73121383B822; Wed, 23 Jun 2021 20:09:04 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 73121383B822
From: "i at maskray dot me" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug gcov-profile/80223] RFE: Exclude functions from profile
 instrumentation
Date: Wed, 23 Jun 2021 20:09:04 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: gcov-profile
X-Bugzilla-Version: 7.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: i at maskray dot me
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-80223-4-7Lfp46Nt15@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-80223-4@http.gcc.gnu.org/bugzilla/>
References: <bug-80223-4@http.gcc.gnu.org/bugzilla/>
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 <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jun 2021 20:09:04 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D80223

--- Comment #21 from Fangrui Song <i at maskray dot me> ---
(In reply to Fangrui Song from comment #20)
> For example, if an inlining pass happens after instrumentation, then the
> function attribute doesn't necessarily need to suppress inlining. After
> instrumentation is done, we can even treat the noprofile attribute as a
> no-op.

Sent too early:)

Amendment: a smart inliner can inline the noprofile callee and then drop
instrumentation code. That will also be an approach which does not break the
"no instrumenting my code" contract. Other approaches can be (probably more
relevant to function specialization/clones): the instrumentation pass can l=
eave
an un-instrumented copy which can be used by a subsequent inliner.

As we can see, all these approaches are much more complex than simply
"suppressing inlining". So I agree that "suppressing inlining" is a good
implementation detail here.=