According to [1] and [2], a 10% runtime regression has hit "channel" Polyhedron benchmark between 29th and 30th of July.
My best uneducated blind shot would be r161570: * recog.c (peep2_do_rebuild_jump_labels, peep2_do_cleanup_cfg): New static variables. (peep2_buf_position): New static function. (peep2_regno_dead_p, peep2_reg_dead_p, peep2_find_free_register, peephole2_optimize): Use it. (peep2_attempt, peep2_update_life): New static functions, broken out of peephole2_optimize. (peep2_fill_buffer): New static function. (peephole2_optimize): Change the main loop to try to fill the buffer with the maximum number of insns before matching them against peepholes. Use a forward scan. Remove special case for targets with conditional execution. * genrecog.c (change_state): Delete dead code. * config/i386/i386.md (peephole2 for arithmetic ops with memory): Rewrite so as not to expect the second insn to have had a peephole applied yet. I will try to confirm this via bisection. [1] http://gcc.opensuse.org/c++bench/polyhedron/polyhedron-summary.txt-2-0.html [2] http://gcc.opensuse.org/c++bench/polyhedron/polyhedron-summary.txt -- Summary: 10% runtime regression on Polyhedron channel banchmark from 29. June 2010 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44867