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 <[EMAIL PROTECTED]> 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 <[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 > > > >
