aboutsummaryrefslogtreecommitdiff
path: root/gcc
diff options
context:
space:
mode:
authorBin Cheng <bin.cheng@arm.com>2014-12-03 05:25:40 +0000
committerBin Cheng <amker@gcc.gnu.org>2014-12-03 05:25:40 +0000
commit51be49774041c9d2b588bb2fd139b5de7454c4f2 (patch)
tree3c382659e0834db1d511d369dd51eb84d07e6f83 /gcc
parent28fe2ab37c2990882795560f8bc345518f9aeb98 (diff)
downloadgcc-51be49774041c9d2b588bb2fd139b5de7454c4f2.zip
gcc-51be49774041c9d2b588bb2fd139b5de7454c4f2.tar.gz
gcc-51be49774041c9d2b588bb2fd139b5de7454c4f2.tar.bz2
target.def (fusion_priority): Wrap code with @smallexample.
* target.def (fusion_priority): Wrap code with @smallexample. * doc/tm.texi: Regenerated. From-SVN: r218301
Diffstat (limited to 'gcc')
-rw-r--r--gcc/ChangeLog5
-rw-r--r--gcc/doc/tm.texi22
-rw-r--r--gcc/target.def22
3 files changed, 33 insertions, 16 deletions
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ceb9e10..cfc6628 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2014-12-03 Bin Cheng <bin.cheng@arm.com>
+
+ * target.def (fusion_priority): Wrap code with @smallexample.
+ * doc/tm.texi: Regenerated.
+
2014-12-03 Manuel López-Ibáñez <manu@gcc.gnu.org>
* diagnostic.c (diagnostic_show_locus): Honor override_column when
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index c54fc71..b9a7251 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -6797,6 +6797,7 @@ instructions.
Given below example:
+@smallexample
ldr r10, [r1, 4]
add r4, r4, r10
ldr r15, [r2, 8]
@@ -6805,6 +6806,7 @@ Given below example:
add r4, r4, r11
ldr r16, [r2, 12]
sub r5, r5, r16
+@end smallexample
On targets like ARM/AArch64, the two pairs of consecutive loads should be
merged. Since peephole2 pass can't help in this case unless consecutive
@@ -6812,19 +6814,22 @@ loads are actually next to each other in instruction flow. That's where
this scheduling fusion pass works. This hook calculates priority for each
instruction based on its fustion type, like:
- ldr r10, [r1, 4] ; fusion_pri=99, pri=96
- add r4, r4, r10 ; fusion_pri=100, pri=100
- ldr r15, [r2, 8] ; fusion_pri=98, pri=92
- sub r5, r5, r15 ; fusion_pri=100, pri=100
- ldr r11, [r1, 0] ; fusion_pri=99, pri=100
- add r4, r4, r11 ; fusion_pri=100, pri=100
- ldr r16, [r2, 12] ; fusion_pri=98, pri=88
- sub r5, r5, r16 ; fusion_pri=100, pri=100
+@smallexample
+ ldr r10, [r1, 4] ; fusion_pri=99, pri=96
+ add r4, r4, r10 ; fusion_pri=100, pri=100
+ ldr r15, [r2, 8] ; fusion_pri=98, pri=92
+ sub r5, r5, r15 ; fusion_pri=100, pri=100
+ ldr r11, [r1, 0] ; fusion_pri=99, pri=100
+ add r4, r4, r11 ; fusion_pri=100, pri=100
+ ldr r16, [r2, 12] ; fusion_pri=98, pri=88
+ sub r5, r5, r16 ; fusion_pri=100, pri=100
+@end smallexample
Scheduling fusion pass then sorts all ready to issue instructions according
to the priorities. As a result, instructions of same fusion type will be
pushed together in instruction flow, like:
+@smallexample
ldr r11, [r1, 0]
ldr r10, [r1, 4]
ldr r15, [r2, 8]
@@ -6833,6 +6838,7 @@ pushed together in instruction flow, like:
sub r5, r5, r15
add r4, r4, r11
sub r5, r5, r16
+@end smallexample
Now peephole2 pass can simply merge the two pairs of loads.
diff --git a/gcc/target.def b/gcc/target.def
index 7c0296d..647ebbe 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -1555,6 +1555,7 @@ instructions.\n\
\n\
Given below example:\n\
\n\
+@smallexample\n\
ldr r10, [r1, 4]\n\
add r4, r4, r10\n\
ldr r15, [r2, 8]\n\
@@ -1563,6 +1564,7 @@ Given below example:\n\
add r4, r4, r11\n\
ldr r16, [r2, 12]\n\
sub r5, r5, r16\n\
+@end smallexample\n\
\n\
On targets like ARM/AArch64, the two pairs of consecutive loads should be\n\
merged. Since peephole2 pass can't help in this case unless consecutive\n\
@@ -1570,19 +1572,22 @@ loads are actually next to each other in instruction flow. That's where\n\
this scheduling fusion pass works. This hook calculates priority for each\n\
instruction based on its fustion type, like:\n\
\n\
- ldr r10, [r1, 4] ; fusion_pri=99, pri=96 \n\
- add r4, r4, r10 ; fusion_pri=100, pri=100 \n\
- ldr r15, [r2, 8] ; fusion_pri=98, pri=92 \n\
- sub r5, r5, r15 ; fusion_pri=100, pri=100 \n\
- ldr r11, [r1, 0] ; fusion_pri=99, pri=100 \n\
- add r4, r4, r11 ; fusion_pri=100, pri=100 \n\
- ldr r16, [r2, 12] ; fusion_pri=98, pri=88 \n\
- sub r5, r5, r16 ; fusion_pri=100, pri=100 \n\
+@smallexample\n\
+ ldr r10, [r1, 4] ; fusion_pri=99, pri=96\n\
+ add r4, r4, r10 ; fusion_pri=100, pri=100\n\
+ ldr r15, [r2, 8] ; fusion_pri=98, pri=92\n\
+ sub r5, r5, r15 ; fusion_pri=100, pri=100\n\
+ ldr r11, [r1, 0] ; fusion_pri=99, pri=100\n\
+ add r4, r4, r11 ; fusion_pri=100, pri=100\n\
+ ldr r16, [r2, 12] ; fusion_pri=98, pri=88\n\
+ sub r5, r5, r16 ; fusion_pri=100, pri=100\n\
+@end smallexample\n\
\n\
Scheduling fusion pass then sorts all ready to issue instructions according\n\
to the priorities. As a result, instructions of same fusion type will be\n\
pushed together in instruction flow, like:\n\
\n\
+@smallexample\n\
ldr r11, [r1, 0]\n\
ldr r10, [r1, 4]\n\
ldr r15, [r2, 8]\n\
@@ -1591,6 +1596,7 @@ pushed together in instruction flow, like:\n\
sub r5, r5, r15\n\
add r4, r4, r11\n\
sub r5, r5, r16\n\
+@end smallexample\n\
\n\
Now peephole2 pass can simply merge the two pairs of loads.\n\
\n\