This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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


> 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.

Reruning CSE is interesting observation.  I guess I should dig archives
for original Michael's analysis.

> that at the -O level. If I remember correctly gcc 3.0 has about the
> same performance as gcc 3.1. Therefore, could you please make your
> patch versus 3.1 available to me. Since the performace of the stepanov
> test is one of gcc 3.1 release criteria and there is a more than 15
> percent slowdown with respect to gcc 2.95.3, I consider the current
> result as a major flaw of gcc 3.1, since the abstraction penalty
> should be close to one for a decent compiler, at least when
> optimization is turned on.

It is more or less special case. Overall 3.1 groks better the code
with lots of abstraction, but in this case 2.95 got particulary lucky.
It runs into similar slowdown only on slightly modified Stephanov as
long as I can remember.

I am attaching the patch to do liveness after addressof generation.
It is quick&dirty sollution and it is relative to 3.2 tree, not 3.1
so it maybe won't apply cleanly for you - just search for the addressof
and put the call to same place as I do in case you want to benchmark it.
I am just bootstrapping the change, but at combine.c it kills about 1-30
instructions per function, so it does something.

Honza

*** toplev.c.old	Sun Mar 17 21:05:50 2002
--- toplev.c	Sun Mar 17 21:07:02 2002
*************** rest_of_compilation (decl)
*** 2794,2799 ****
--- 2794,2802 ----
    if (optimize)
      purge_all_dead_edges (0);
    reg_scan (insns, max_reg_num (), 1);
+   life_analysis (insns, rtl_dump_file,
+ 		 PROP_SCAN_DEAD_CODE | PROP_KILL_DEAD_CODE| PROP_EQUAL_NOTES);
+   reg_scan (insns, max_reg_num (), 1);
  
    close_dump_file (DFI_addressof, print_rtl, insns);
  


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