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 trials with.
-girish --- Jan Hubicka <[EMAIL PROTECTED]> wrote: > > On Wed, Jul 20, 2005 at 10:45:01AM -0700, girish > vaitheeswaran wrote: > > > > --- Steven Bosscher <[EMAIL PROTECTED]> 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 >
