diff mbox

[DOC] Fix wrong documentation for TARGET_SCHED_FUSION_PRIORITY

Message ID 000601d00dda$903bbc90$b0b335b0$@arm.com
State New
Headers show

Commit Message

Bin Cheng Dec. 2, 2014, 2:49 a.m. UTC
Hi,
This is an obvious patch fixing wrong documentation for
TARGET_SCHED_FUSION_PRIORITY.
Html file generated as expected now.  Will commit it in 24h if no objection.

2014-12-02  Bin Cheng  <bin.cheng@arm.com>

	* target.def (fusion_priority): Wrap code with @smallexample.
	* doc/tm.texi: Regenerated.
diff mbox

Patch

Index: gcc/doc/tm.texi
===================================================================
--- gcc/doc/tm.texi	(revision 218037)
+++ gcc/doc/tm.texi	(working copy)
@@ -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 instructi
 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.
 
Index: gcc/target.def
===================================================================
--- gcc/target.def	(revision 218037)
+++ gcc/target.def	(working copy)
@@ -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 instructi
 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\