Slowdowns in code generated by GCC>=3.3

[Zack Weinberg]

Peter Barada <peter@the-baradas.com> writes:

> Wouldn't it be better to make the compiler not do
> tail-merging/crossjumping unless the savings makes it wortwhile;
> i.e. don't do the jump to save less than N instructions(where in
> this case, it actaully *increases* the instruction count by one)?

I don't think you understand the problem.  The control flow graph
generated from the original code contains a very large number of basic
blocks each of which begins and ends with an abnormal edge.  The early
phases of optimization go into a very bad performance regime when
faced with such a control flow graph -- we're talking hours to compile
one function.

The tail merge in this case is done in spite of its making the
generated code worse; its sole function is to get the early optimizers
out of the bad performance regime.  It's *supposed* to be undone at
the end.  The bug is that that isn't happening.

(An alternative would be to detect the problem basic block structure
and disable the optimizations that can't handle it; if I remember
correctly which those are, they are unlikely to do anything useful on
such a function anyway.)

In any case, we're definitely in patches-are-welcome mode with regard
to getting this fixed.

zw