Daniel Berlin wrote:
On Thu, 2005-12-15 at 00:48 +0100, Steven Bosscher wrote:
Hi,
Someone caused a >10% compile time regression yesterday for CSiBE, see
http://www.csibe.org/draw-diag.php?branchid=mainline&flags=-Os&rel_flag=--none--&dataview=Timeline&finish_button=Finish&draw=sbs&view=1&basephp=l-sbs
Gr.
Steven
This is very very bad.
Joern, i'd imagine this was your patch.
I think this is related to using register liveness information from
flow. My original if-conversion patch
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03281.html used a simple
linear-time
algorithm to identify registers that are local to each basic block.
I can think of two things that could cause a noticable slowdown:
- comparison of global_live_at_end in struct_equiv_init. Most call
sites call gcc_unreachable when struct_equiv_init fails. If an
additional parameter is passed into struct_equiv_init to tell if the
the comparison may fail, we can optimize the sanity check out for
!ENABLE_CHECKING.
- The call to update_life_info_in_dirty_blocks when one of the compared
blocks is dirty. I'm not sure if we could get away with doing a local
update, and/or starting the update only for the blocks under
consideration. If we don't have to do the global_live_at_end
comparison, we can probably also skip the update if only one of the
blocks is dirty, and use the global_live_at_end from the block that is
not dirty.
A further improvement might be to remove the regset comparison from
struct_equiv_init altogether, and only make sure we use a
global_live_at_end that is right for at least one of the
blocks. The regsets can be compared later when we have matched all the
edges, maybe even the entire block.
We could also go back to makling sure we have consistent data flow
information at the start of the pass, and keep the bits that we need
up-to-date as we go along.
