Slowdowns in code generated by GCC>=3.3

[Mike Stump]

On Oct 23, 2004, at 5:40 AM, Remko Troncon wrote:
>> Another thought, you can binary search the compiler sources from cvs,
>> compiling your application at each instance to determine the patch 
>> that
>> went in that regressed performance for you.
>
> I did a search through GCC CVS to find out which patch caused our 
> factor
> 3 slowdown. Apparently, it is the patch with this ChangeLog entry:
>
> 2003-02-15  Richard Henderson  <rth@redhat.com>
>         * bb-reorder.c (find_traces_1_round): Don't connect easy to 
> copy
>         successors with multiple predecessors.
>         (connect_traces): Try harder to copy traces of length 1.
>         * function.h (struct function): Add computed_goto_common_label,
>         computed_goto_common_reg.
>         * function.c (free_after_compilation): Zap them.
>         * stmt.c (expand_computed_goto): Use them to produce one
>         indirect branch per function.

Wait, we're not done yet, that is just the first step.  The next step 
is to find an instance of changed code generation...  It would help if 
you gperf or gcov your code, and then find a hot instance of the code 
that changed.  gcc -save-temps can be used to preserve the preprocessed 
source code and the assembly.

 From there, if you can, trim down the extraneous code from the .i/.ii 
file and then submit that file as a bug report, with the flags, then 
generated .s before and after, and the net effect of the change (3x 
application slowdown) and the fact it is a regression and a pointer to 
the above changelog entry and the timings you get with and without 
that.