From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9585 invoked by alias); 1 Aug 2007 21:51:09 -0000 Received: (qmail 9575 invoked by uid 22791); 1 Aug 2007 21:51:08 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Aug 2007 21:50:59 +0000 Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id l71Loo0Q007483; Wed, 1 Aug 2007 22:50:51 +0100 Received: from localhost.localdomain.google.com (dhcp-172-18-116-220.corp.google.com [172.18.116.220]) (authenticated bits=0) by zps38.corp.google.com with ESMTP id l71LoErE026872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Aug 2007 14:50:18 -0700 To: "Andrew Pinski" Cc: gcc-patches@gcc.gnu.org Subject: Re: PATCH RFC: More control over which functions are instrumented References: From: Ian Lance Taylor Date: Wed, 01 Aug 2007 21:51:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-08/txt/msg00082.txt.bz2 "Andrew Pinski" writes: > On 01 Aug 2007 13:21:25 -0700, Ian Lance Taylor wrote: > > We've had a -finstrument-functions option for a while, which inserts > > calls to __cyg_profile_func_enter and __cyg_profile_func_exit at the > > start and end of each function. This can be handy, but it is rather > > less handy in practice with C++. The issue is simply that there are a > > bunch of inline functions which it is uninteresting to instrument, and > > these functions come from standard headers so you can't really avoid > > compiling them with -finstrument-functions. > > I rather have instrumentation done differently than it is now instead > of these options. Just have an option to turn off instrumentation for > functions that get inlined (so the instrumentation happens after > inlining). These options help but you still have to maintain a list > of functions which can get hard to maintain unlike instrumenting after > inlining. -finstrument-functions-exclude-function-list is there because it seems odd to not have it, but the more commonly used option will be -finstrument-functions-exclude-file-list. Note that files are matched as substrings, so you can say -finstrument-functions-exclude-file-list=include/c++ to exclude any function defined in a file in ...include/c++... Turning off instrumentation for functions which are inlined is useful but it is not the same. It is reasonable to actually want instrumentation for inlined functions that you wrote in an optimized build. That is, I see the ideas as independent; I don't see why one should block the other. Ian