From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11370 invoked by alias); 3 Jun 2011 20:13:22 -0000 Received: (qmail 11361 invoked by uid 22791); 3 Jun 2011 20:13:21 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 03 Jun 2011 20:13:07 +0000 Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p53KD6jq029855 for ; Fri, 3 Jun 2011 13:13:06 -0700 Received: from pzk9 (pzk9.prod.google.com [10.243.19.137]) by wpaz1.hot.corp.google.com with ESMTP id p53KChmU005273 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 3 Jun 2011 13:13:04 -0700 Received: by pzk9 with SMTP id 9so1135388pzk.5 for ; Fri, 03 Jun 2011 13:13:04 -0700 (PDT) Received: by 10.68.31.166 with SMTP id b6mr935261pbi.198.1307131984292; Fri, 03 Jun 2011 13:13:04 -0700 (PDT) Received: from coign.google.com (dhcp-172-18-113-207.mtv.corp.google.com [172.18.113.207]) by mx.google.com with ESMTPS id n1sm1683827pbi.95.2011.06.03.13.13.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2011 13:13:03 -0700 (PDT) From: Ian Lance Taylor To: Paul Dovydaitis Cc: gcc-help@gcc.gnu.org Subject: Re: Details on -fprofile-use and associated optimization flags References: Date: Fri, 03 Jun 2011 20:13:00 -0000 In-Reply-To: (Paul Dovydaitis's message of "Fri, 3 Jun 2011 13:04:00 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg00077.txt.bz2 Paul Dovydaitis writes: > I have been playing around with the profile guided optimization flags > in GCC and had a few questions. I actually noticed that with the > particular application I was profiling, I in some cases got worse > results after recompiling with -fprofile-use and re-running the same > test I used to generate the profile. > > I could not find any detailed documentation about how the profile is > applied during the optimization steps, but my working hypothesis is as > follows. The application in question is very latency sensitive, so it > spins in a tight loop while polling for data from various sources. > When data is received, it then processes it =E2=80=93 and this processing= is > the portion in which speed is most important and which I am timing. > If one were to look at hit counts for individual functions or source > lines, though, it would appear that the polling loop was =E2=80=9Chot=E2= =80=9D while > everything else by comparison was extremely =E2=80=9Ccold=E2=80=9D. Glob= al > optimizations that use this sort of data would then likely hurt, > rather than help those processing times. While it's hard to know for sure, your explanation is plausible. > What optimizations does -fprofile-use turn on that would be sensitive > to this sort of behavior? Does this seem like a reasonable > explanation, and if so is there anything I can tweak to help? The > specific flags that -fprofile-use turns on (-fbranch-probabilities, > -fvpt, -funroll-loops, -fpeel-loops and =E2=80=93ftracer) don=E2=80=99t s= eem like they > would be affected since these optimizations appear local in scope, but > I assume there are other things happening under the hood. Profiling affects inlining decisions. Ian