This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH] Fix code hoisting dataflow computation order
- From: "Steven Bosscher" <stevenb dot gcc at gmail dot com>
- To: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 28 Oct 2007 22:37:53 +0100
- Subject: [PATCH] Fix code hoisting dataflow computation order
Hi,
The computation of VBEIN and VBEOUT in gcse.c's code hoisting implementation
appears to be performed in the wrong order, if you ask me.
The explanation is in my list of issues with gcc's code hoisting
implementation, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33828#c9
With the attached patch, compute_code_hoist_vbeinout() does converge
in two iterations for the test case in that Bugzilla comment.
This patch has not been properly tested yet. I'm posting it mostly
because this is such an embarrassing mistake, and because this might
be acceptable for gcc 4.3 as a bug fix (there should be a noticeable
compiler speed improvement when compiling large functions with -Os).
If someone wants to pick this up and give it the necessary TLC to get
it into the FSF gcc,, please go ahead :-)
Gr.
Steven
* gcse.c (compute_code_hoist_vbeinout): Fix order of computation
of VBEIN and VBEOUT.
Index: gcse.c
===================================================================
--- gcse.c (revision 129634)
+++ gcse.c (working copy)
@@ -4754,10 +4754,14 @@
the convergence. */
FOR_EACH_BB_REVERSE (bb)
{
- changed |= sbitmap_a_or_b_and_c_cg (hoist_vbein[bb->index], antloc[bb->index],
- hoist_vbeout[bb->index], transp[bb->index]);
if (bb->next_bb != EXIT_BLOCK_PTR)
- sbitmap_intersection_of_succs (hoist_vbeout[bb->index], hoist_vbein, bb->index);
+ sbitmap_intersection_of_succs (hoist_vbeout[bb->index],
+ hoist_vbein, bb->index);
+
+ changed |= sbitmap_a_or_b_and_c_cg (hoist_vbein[bb->index],
+ antloc[bb->index],
+ hoist_vbeout[bb->index],
+ transp[bb->index]);
}
passes++;