This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gcc 3.1 performance regressions with respect to 2.95.3


> In message <20020317180245.GB10722@atrey.karlin.mff.cuni.cz>, Jan Hubicka write
> s:
>  > > It seems that the option -frerun-cse-after-loop causes a 10 percent
>  > > slowdown. But I am not sure if that was the option you asked me to
>  > > turn off. On the other hand even when -fno-rerun-cse-after-loop is
>  > > added to the -O2 optimization level the performance is still slower
>  > 
>  > I now realise that there is no way to turn off loop optimizer, that ineed
>  > is mistake.  I will send patch for this together with crossjumping.
>  > This is another pass that may well be responsible for peroformance loss
>  > and misscompilations so it should be possible to disable it.
> crossjumping is not always a performance win -- if you look at the old
> crossjumping code, it had heuristics to guess when crossjumping would 
> not be profitable.  Perhaps you should review the code and add some heuristics
> to your new version.

I did in previous email.  Note that old crossjumping code heuristics is
obsoletted by bb-reorder that is able to get hot paths w/o jumps it was
trying to avoid.  The problem is that I actually crossjump the loop into
it's preheader.  It is also not problem in longer term as cfg-branch already
do have new bb-reorder impleemntation that re-duplicates or rotate the loop
when profitable.

I will send another patch with flags to disable crossjumping and loop
optimizer as we should have knob for this IMO.

Honza
> 
> jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]