report.tex 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319
  1. \documentclass[10pt,a4paper]{article}
  2. \usepackage[latin1]{inputenc}
  3. \usepackage{amsmath}
  4. \usepackage{amsfonts}
  5. \usepackage{amssymb}
  6. \usepackage{booktabs}
  7. \usepackage{graphicx}
  8. \usepackage{listings}
  9. \usepackage{subfigure}
  10. \usepackage{float}
  11. \usepackage{hyperref}
  12. \title{Peephole Optimizer}
  13. \author{Jayke Meijer (6049885), Richard Torenvliet (6138861), Tadde\"us Kroes
  14. (6054129)}
  15. \begin{document}
  16. \maketitle
  17. \tableofcontents
  18. \pagebreak
  19. \section{Introduction}
  20. The goal of the assignment is to implement the optimization stage of the
  21. compiler. To reach this goal the parser and the optimizer part of the compiler
  22. have to be implemented.
  23. The output of the xgcc cross compiler on a C program is our input. The output
  24. of the xgcc cross compiler is in the form of Assembly code, but not optimized.
  25. Our assignment includes a number of C programs. An important part of the
  26. assignment is parsing the data. Parsing the data is done with Lex and Yacc. The
  27. Lexer is a program that finds keywords that meets the regular expression
  28. provided in the Lexer. After the Lexer, the Yaccer takes over. Yacc can turn
  29. the keywords in to an action.
  30. \section{Design}
  31. There are two general types of optimizations of the assembly code, global
  32. optimizations and optimizations on a so-called basic block. These optimizations
  33. will be discussed separately
  34. \subsection{Global optimizations}
  35. We only perform one global optimization, which is optimizing branch-jump
  36. statements. The unoptimized Assembly code contains sequences of code of the
  37. following structure:
  38. \begin{verbatim}
  39. beq ...,$Lx
  40. j $Ly
  41. $Lx: ...
  42. \end{verbatim}
  43. This is inefficient, since there is a jump to a label that follows this code.
  44. It would be more efficient to replace the branch statement with a \texttt{bne}
  45. (the opposite case) to the label used in the jump statement. This way the jump
  46. statement can be eliminated, since the next label follows anyway. The same can
  47. of course be done for the opposite case, where a \texttt{bne} is changed into a
  48. \texttt{beq}.
  49. Since this optimization is done between two series of codes with jumps and
  50. labels, we can not perform this code during the basic block optimizations. The
  51. reason for this will become clearer in the following section.
  52. \subsection{Basic Block Optimizations}
  53. Optimizations on basic blocks are a more important part of the optimizer.
  54. First, what is a basic block? A basic block is a sequence of statements
  55. guaranteed to be executed in that order, and that order alone. This is the case
  56. for a piece of code not containing any branches or jumps.
  57. To create a basic block, you need to define what is the leader of a basic
  58. block. We call a statement a leader if it is either a jump/branch statement, or
  59. the target of such a statement. Then a basic block runs from one leader until
  60. the next leader.
  61. There are quite a few optimizations we perform on these basic blocks, so we
  62. will describe the types of optimizations here in stead of each optimization.
  63. \subsubsection*{Standard peephole optimizations}
  64. These are optimizations that simply look for a certain statement or pattern of
  65. statements, and optimize these. For example,
  66. \begin{verbatim}
  67. mov $regA,$regB
  68. instr $regA, $regA,...
  69. \end{verbatim}
  70. can be optimized into
  71. \begin{verbatim}
  72. instr $regA, $regB,...
  73. \end{verbatim}
  74. since the register \texttt{\$regA} gets overwritten by the second instruction
  75. anyway, and the instruction can easily use \texttt{\$regB} in stead of
  76. \texttt{\$regA}. There are a few more of these cases, which are the same as
  77. those described on the practicum page
  78. \footnote{\url{http://staff.science.uva.nl/~andy/compiler/prac.html}} and in
  79. Appendix \ref{opt}.
  80. \subsubsection*{Common subexpression elimination}
  81. A more advanced optimization is common subexpression elimination. This means
  82. that expensive operations as a multiplication or addition are performed only
  83. once and the result is then `copied' into variables where needed.
  84. \begin{verbatim}
  85. addu $2,$4,$3 addu = $t1, $4, $3
  86. ... mov = $2, $t1
  87. ... -> ...
  88. ... ...
  89. addu $5,$4,$3 mov = $4, $t1
  90. \end{verbatim}
  91. A standard method for doing this is the creation of a DAG or Directed Acyclic
  92. Graph. However, this requires a fairly advanced implementation. Our
  93. implementation is a slightly less fancy, but easier to implement.
  94. We search from the end of the block up for instructions that are eligible for
  95. CSE. If we find one, we check further up in the code for the same instruction,
  96. and add that to a temporary storage list. This is done until the beginning of
  97. the block or until one of the arguments of this expression is assigned.
  98. We now add the instruction above the first use, and write the result in a new
  99. variable. Then all occurrences of this expression can be replaced by a move of
  100. from new variable into the original destination variable of the instruction.
  101. This is a less efficient method then the dag, but because the basic blocks are
  102. in general not very large and the execution time of the optimizer is not a
  103. primary concern, this is not a big problem.
  104. \subsubsection*{Fold constants}
  105. \subsubsection*{Copy propagation}
  106. Copy propagation `unpacks' a move instruction, by replacing its destination
  107. address with its source address in the code following the move instruction.
  108. This is not a direct optimization, but this does allow for a more effective
  109. dead code elimination.
  110. The code of the block is checked linearly. When a move operation is
  111. encountered, the source and destination address of this move are stored. When
  112. a normal operation with a source and a destination address are found, a number
  113. of checks are performed.
  114. The first check is whether the destination address is stored as a destination
  115. address of a move instruction. If so, this move instruction is no longer valid,
  116. so the optimizations can not be done. Otherwise, continue with the second
  117. check.
  118. In the second check, the source address is compared to the destination
  119. addresses of all still valid move operations. If these are the same, in the
  120. current operation the found source address is replaced with the source address
  121. of the move operation.
  122. An example would be the following:
  123. \begin{verbatim}
  124. move $regA, $regB move $regA, $regB
  125. ... ...
  126. Code not writing $regA, -> ...
  127. $regB ...
  128. ... ...
  129. addu $regC, $regA, ... addu $regC, $regB, ...
  130. \end{verbatim}
  131. This code shows that \texttt{\$regA} is replaced with \texttt{\$regB}. This
  132. way, the move instruction might have become useless, and it will then be
  133. removed by the dead code elimination.
  134. \subsubsection*{Algebraic transformations}
  135. \section{Implementation}
  136. We decided to implement the optimization in Python. We chose this programming
  137. language because Python is an easy language to manipulate strings, work
  138. object-oriented etc.
  139. It turns out that a Lex and Yacc are also available as a Python module,
  140. named PLY(Python Lex-Yacc). This allows us to use one language, Python, instead
  141. of two, i.e. C and Python. Also no debugging is needed in C, only in Python
  142. which makes our assignment more feasible.
  143. The program has three steps, parsing the Assembly code into a datastructure we
  144. can use, the so-called Intermediate Representation, performing optimizations on
  145. this IR and writing the IR back to Assembly.
  146. \subsection{Parsing}
  147. The parsing is done with PLY, which allows us to perform Lex-Yacc tasks in
  148. Python by using a Lex-Yacc like syntax. This way there is no need to combine
  149. languages like we should do otherwise since Lex and Yacc are coupled with C.
  150. The decision was made to not recognize exactly every possible instruction in
  151. the parser, but only if something is for example a command, a comment or a gcc
  152. directive. We then transform per line to an object called a Statement. A
  153. statement has a type, a name and optionally a list of arguments. These
  154. statements together form a statement list, which is placed in another object
  155. called a Block. In the beginning there is one block for the entire program, but
  156. after global optimizations this will be separated in several blocks that are
  157. the basic blocks.
  158. \subsection{Optimizations}
  159. The optimizations are done in two different steps. First the global
  160. optimizations are performed, which are only the optimizations on branch-jump
  161. constructions. This is done repeatedly until there are no more changes.
  162. After all possible global optimizations are done, the program is seperated into
  163. basic blocks. The algorithm to do this is described earlier, and means all
  164. jump and branch instructions are called leaders, as are their targets. A basic
  165. block then goes from leader to leader.
  166. After the division in basic blocks, optimizations are performed on each of
  167. these basic blocks. This is also done repeatedly, since some times several
  168. steps can be done to optimize something.
  169. \subsection{Writing}
  170. Once all the optimizations have been done, the IR needs to be rewritten into
  171. Assembly code. After this step the xgcc crosscompiler can make binary code from
  172. the generated Assembly code.
  173. The writer expects a list of statements, so first the blocks have to be
  174. concatenated again into a list. After this is done, the list is passed on to
  175. the writer, which writes the instructions back to Assembly and saves the file
  176. so we can let xgcc compile it.
  177. \section{Results}
  178. \subsection{pi.c}
  179. \subsection{acron.c}
  180. \subsection{whet.c}
  181. \subsection{slalom.c}
  182. \subsection{clinpack.c}
  183. \section{Conclusion}
  184. \appendix
  185. \section{List of all optimizations}
  186. \label{opt}
  187. \textbf{Global optimizations}
  188. \begin{verbatim}
  189. beq ...,$Lx bne ...,$Ly
  190. j $Ly -> $Lx: ...
  191. $Lx: ...
  192. bne ...,$Lx beq ...,$Ly
  193. j $Ly -> $Lx: ...
  194. $Lx: ...
  195. \end{verbatim}
  196. \textbf{Standard basic block optimizations}
  197. \begin{verbatim}
  198. mov $regA,$regA -> --- // remove it
  199. mov $regA,$regB -> instr $regA, $regB,...
  200. instr $regA, $regA,...
  201. instr $regA,... instr $4,...
  202. mov [$4-$7], $regA -> jal XXX
  203. jal XXX
  204. sw $regA,XXX -> sw $regA, XXX
  205. ld $regA,XXX
  206. shift $regA,$regA,0 -> --- // remove it
  207. add $regA,$regA,X -> lw ...,X($regA)
  208. lw ...,0($regA)
  209. \end{verbatim}
  210. \textbf{Advanced basic block optimizations}
  211. \begin{verbatim}
  212. # Common subexpression elimination
  213. addu $regA, $regB, 4 addu $regD, $regB, 4
  214. ... move $regA, $regD
  215. Code not writing $regB -> ...
  216. ... ...
  217. addu $regC, $regB, 4 move $regC, $regD
  218. # Constant folding
  219. # Copy propagation
  220. move $regA, $regB move $regA, $regB
  221. ... ...
  222. Code not writing $regA, -> ...
  223. $regB ...
  224. ... ...
  225. addu $regC, $regA, ... addu $regC, $regB, ...
  226. # Algebraic transformations
  227. addu $regA, $regB, 0 -> move $regA, $regB
  228. subu $regA, $regB, 0 -> move $regA, $regB
  229. mult $regA, $regB, 1 -> move $regA, $regB
  230. mult $regA, $regB, 0 -> li $regA, 0
  231. mult $regA, $regB, 2 -> sll $regA, $regB, 1
  232. \end{verbatim}
  233. \end{document}