Re: -fprofile-generate and -fprofile-use

[girish vaitheeswaran <girish_vaithees at yahoo dot com>]

I have done quite a few experiments with this to
narrow down the problem. The performance numbers are 
slower compared to *No Feedback optimization with just
-O3* Here are some of them. All the experiments were
done on a new build-area in order to eliminate effects
of old feedback files.

1. I built the app using -O3 and -fprofile-generate to
generate the feedback data. I then ran the workload
and then recompiled the app using -O3 and
-fprofile-use [app was 20% slower]

2. I built the app using -O3 and -fprofile-generate to
generate the feedback data. I then ran the workload
and then recompiled the app using -O3 and
-fprofile-use -fno-vpt -fno-unroll-loops
-fno-peel-loops -fno-tracer (Which is turn off all the
flags used by -fprofile-use) [App was still 20%
slower]

3. I have tried selectively turning of some of the
other flags in the above list as well, but the
performance regression persists.

4. I tried with the older flags namely -fprofile-arcs
and -fbranch-probabilities still no help.

Can someone help me out on how to proceed with this.

Thanks
-girish


--- Jan Hubicka <hubicka@ucw.cz> wrote:

> > I started with a clean slate in my build
> environment
> > and did not have any residual files hanging
> around.
> > Are the steps I have indicated in my earlier email
> > correct. Is there a way I can break down the
> problem
> > into a smaller sub-set of flags and eliminate the
> flag
> > causing the performance problem. What I mean is
> since
> > -fprofile-generate and -fprofile-use enable a
> bunch of
> > flags, would it make sense to avoid profiling and
> try
> > out some of the individual flags on a trial and
> error
> > basis. If so what would be the flags to start the
> It would be probably better to just turn off the
> individual
> optimizations with -fprofile-use (for optimizations
> that are implied by
> this flag there should be no need to re-profile each
> time).
> If you can find particular optimization that gets
> out of control, it
> would be lot easier to fix it...
> 
> Honza
> > trials with.
> > 
> > -girish 
> > 
> > --- Jan Hubicka <hubicka@ucw.cz> wrote:
> > 
> > > > On Wed, Jul 20, 2005 at 10:45:01AM -0700,
> girish
> > > vaitheeswaran wrote:
> > > > > > --- Steven Bosscher <stevenb@suse.de>
> wrote:
> > > > > > 
> > > > > > > On Wednesday 20 July 2005 18:53, girish
> > > vaitheeswaran wrote:
> > > > > > > > I am seeing a 20% slowdown with
> feedback
> > > optimization.
> > > > > > > > Does anyone have any thoughts on this.
> > > > > > > 
> > > > > > > My first thought is that you should
> probably
> > > first
> > > > > > > tell what compiler
> > > > > > > you are using.
> > > > >
> > > > > I am using gcc 3.4.3
> > > > > -girish
> > > > 
> > > > Which platform?  I've seen slower code for
> > > profile-directed optimizations
> > > > on powerpc64-linux with GCC 4.0 and mainline. 
> > > It's a bug, but I haven't
> > > > looked into it enough to provide a small test
> case
> > > for a problem report.
> > > 
> > > Actually I would be very interested in seeing
> > > testcases such as those.
> > > (and the Girish' slowdown too if possible).  In
> > > general some slowdowns
> > > in side corners are probably unavoidable but
> both
> > > 3.4.3 and 4.0 seems to
> > > have pretty consistent improvements with
> profiling
> > > at least for SPEC and
> > > i386 I am testing pretty regularly.
> > > Such slodowns usually indicate problems like
> > > incorrectly updated profile
> > > or incorrectly readed in profile because of
> > > missmatch in CFGs in between
> > > profile and feedback run that are rather
> dificult to
> > > notice and hunt
> > > down...
> > > 
> > > Honza
> > > > 
> > > > Janis
> > > 
>