From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-166436-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 31595 invoked by alias); 5 Jan 2011 23:55:23 -0000
Received: (qmail 31581 invoked by uid 22791); 5 Jan 2011 23:55:22 -0000
X-SWARE-Spam-Status: No, hits=-0.1 required=5.0	tests=AWL,BAYES_05,MAY_BE_FORGED,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from whisker.bluecoat.com (HELO whisker.bluecoat.com) (216.52.23.28)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Jan 2011 23:55:17 +0000
Received: from bcs-mail04.internal.cacheflow.com (bcsmail04.internal.cacheflow.com [10.2.2.56] (may be forged))	by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p05NtB4L018623;	Wed, 5 Jan 2011 15:55:15 -0800 (PST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Subject: RE: call for libstdc++ profile mode diagnostic ideas
Date: Wed, 05 Jan 2011 23:55:00 -0000
Message-ID: <95F62D0687BC854194F0005299FD511502603D78@bcs-mail04.internal.cacheflow.com>
In-Reply-To: <AANLkTikB_SC0gn+K=FuLF1cibu+cFTWVQttMEyBtp0aq@mail.gmail.com>
References: <AANLkTikTyigr6r4uWHDjCo=9qPvQUQtG9Z=FrGr5uwiq@mail.gmail.com><95F62D0687BC854194F0005299FD51150258FEC7@bcs-mail04.internal.cacheflow.com> <AANLkTikB_SC0gn+K=FuLF1cibu+cFTWVQttMEyBtp0aq@mail.gmail.com>
From: "Hargett, Matt" <matt.hargett@bluecoat.com>
To: "Xinliang David Li" <davidxl@google.com>
Cc: <gcc@gcc.gnu.org>
X-IsSubscribed: yes
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2011-01/txt/msg00076.txt.bz2

> Your first example points to a weakness in the compiler optimization.
> If base_string constructor is inlined, the compiler should be able to
> figure out both 'name' and the heap memory it points to can not be
> modified by the call to notify, and therefore hoist access name.c_str
> () and name.length () out of the loop. Even without inlining, with
> more powerful modeling of standard function side effect (e.g.,
> base_string ctor does not expose name's address), the same
> optimization should be performed.

You're right, 4.5.1 and current trunk appear to correctly hoist those acces=
ses out of the loop.

It would still be useful for codebases that are built using different compi=
lers that don't have this kind of optimization, though.

> > Example:
> >
> > #include <string>
> > #include <cstdio>
> >
> > void notify(const char* printable) { printf("%s\n", printable); }
> >
> > int main(void)
> > {
> > =A0std::string name("bob");
> > =A0for (int i =3D 0; i < name.length(); i++)
> > =A0{
> > =A0 =A0notify(name.c_str());
> > =A0}
> >
> > =A0return 0;
> > }