Patchwork bb partitioning vs optimize_function_for_speed_p

login
register
mail settings
Submitter Bernd Schmidt
Date Aug. 26, 2011, 2:47 p.m.
Message ID <4E57B20F.7000307@codesourcery.com>
Download mbox | patch
Permalink /patch/111791/
State New
Headers show

Comments

Bernd Schmidt - Aug. 26, 2011, 2:47 p.m.
In rest_of_reorder_blocks, we avoid reordering if
!optimize_function_for_speed_p. However, we still call
insert_section_bounary_note, which can cause problems because now, if we
have a sequence of HOT-COLD-HOT blocks, the second set of HOT blocks
will end up in the cold section. This causes assembler failures when
using exception handling (subtracting labels from different sections).

Unfortunately, the only way I have of reproducing it is to apply a
67-patch quilt tree backporting the preliminary shrink-wrapping patches
to gcc-4.6; then we get

FAIL: g++.dg/tree-prof/partition2.C compilation,  -Os  -fprofile-use

However, the problem is reasonably obvious. Bootstrapped and currently
testing in the aforementioned 4.6 tree. Ok for trunk after testing there?


Bernd
* bb-reorder.c (insert_section_boundary_note): Only do it if
	we reordered the blocks; i.e. not if !optimize_function_for_speed_p.
Jeff Law - Aug. 29, 2011, 4:02 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/26/11 08:47, Bernd Schmidt wrote:
> In rest_of_reorder_blocks, we avoid reordering if 
> !optimize_function_for_speed_p. However, we still call 
> insert_section_bounary_note, which can cause problems because now, if
> we have a sequence of HOT-COLD-HOT blocks, the second set of HOT
> blocks will end up in the cold section. This causes assembler
> failures when using exception handling (subtracting labels from
> different sections).
> 
> Unfortunately, the only way I have of reproducing it is to apply a 
> 67-patch quilt tree backporting the preliminary shrink-wrapping
> patches to gcc-4.6; then we get
> 
> FAIL: g++.dg/tree-prof/partition2.C compilation,  -Os  -fprofile-use
> 
> However, the problem is reasonably obvious. Bootstrapped and
> currently testing in the aforementioned 4.6 tree. Ok for trunk after
> testing there?
OK after testing.

Thanks,
Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOW7f/AAoJEBRtltQi2kC7h6oIALoZd5k63vCHCcDh6rHShEA6
oecu5FILQq3Fi0aSgSya0z8k8dUxQ/5lPK0Ntk+cDc+6Pp/7UIcViRSpg9rQeqWv
DSAuHcjfUP25SR0EpzUSrerRE38MM5kCpryuQEDFNW1gZC+NCPaeY1KWq4LXnzXw
i3LCVW75p41GXSmSW1rPcR6yXyaaDCbyKA8bijRLjTrXE5R40cfvL/5W7g8SelQG
V/9RZ79kG7b4R5tQS9ozUgOlbXLj+UqOh5u5Dsd1Y8unH6GaqD5J+eGk782jqVKg
CrEJfA1TP9FLkt+X583iO1wMjqibQ4jU/tOW14JFPE3v/Elwb75P7HfMF1r+yf4=
=Yytx
-----END PGP SIGNATURE-----

Patch

Index: gcc/bb-reorder.c
===================================================================
--- gcc/bb-reorder.c	(revision 178030)
+++ gcc/bb-reorder.c	(working copy)
@@ -1965,8 +1965,11 @@  insert_section_boundary_note (void)
   rtx new_note;
   int first_partition = 0;
 
-  if (flag_reorder_blocks_and_partition)
-    FOR_EACH_BB (bb)
+  if (!flag_reorder_blocks_and_partition
+      || !optimize_function_for_speed_p (cfun))
+    return;
+
+  FOR_EACH_BB (bb)
     {
       if (!first_partition)
 	first_partition = BB_PARTITION (bb);