Parsing-pass.html 7.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164
  1. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
  2. <html>
  3. <!-- Copyright (C) 1988-2017 Free Software Foundation, Inc.
  4. Permission is granted to copy, distribute and/or modify this document
  5. under the terms of the GNU Free Documentation License, Version 1.3 or
  6. any later version published by the Free Software Foundation; with the
  7. Invariant Sections being "Funding Free Software", the Front-Cover
  8. Texts being (a) (see below), and with the Back-Cover Texts being (b)
  9. (see below). A copy of the license is included in the section entitled
  10. "GNU Free Documentation License".
  11. (a) The FSF's Front-Cover Text is:
  12. A GNU Manual
  13. (b) The FSF's Back-Cover Text is:
  14. You have freedom to copy and modify this GNU Manual, like GNU
  15. software. Copies published by the Free Software Foundation raise
  16. funds for GNU development. -->
  17. <!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ -->
  18. <head>
  19. <title>GNU Compiler Collection (GCC) Internals: Parsing pass</title>
  20. <meta name="description" content="GNU Compiler Collection (GCC) Internals: Parsing pass">
  21. <meta name="keywords" content="GNU Compiler Collection (GCC) Internals: Parsing pass">
  22. <meta name="resource-type" content="document">
  23. <meta name="distribution" content="global">
  24. <meta name="Generator" content="makeinfo">
  25. <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  26. <link href="index.html#Top" rel="start" title="Top">
  27. <link href="Option-Index.html#Option-Index" rel="index" title="Option Index">
  28. <link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
  29. <link href="Passes.html#Passes" rel="up" title="Passes">
  30. <link href="Cilk-Plus-Transformation.html#Cilk-Plus-Transformation" rel="next" title="Cilk Plus Transformation">
  31. <link href="Passes.html#Passes" rel="prev" title="Passes">
  32. <style type="text/css">
  33. <!--
  34. a.summary-letter {text-decoration: none}
  35. blockquote.smallquotation {font-size: smaller}
  36. div.display {margin-left: 3.2em}
  37. div.example {margin-left: 3.2em}
  38. div.indentedblock {margin-left: 3.2em}
  39. div.lisp {margin-left: 3.2em}
  40. div.smalldisplay {margin-left: 3.2em}
  41. div.smallexample {margin-left: 3.2em}
  42. div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
  43. div.smalllisp {margin-left: 3.2em}
  44. kbd {font-style:oblique}
  45. pre.display {font-family: inherit}
  46. pre.format {font-family: inherit}
  47. pre.menu-comment {font-family: serif}
  48. pre.menu-preformatted {font-family: serif}
  49. pre.smalldisplay {font-family: inherit; font-size: smaller}
  50. pre.smallexample {font-size: smaller}
  51. pre.smallformat {font-family: inherit; font-size: smaller}
  52. pre.smalllisp {font-size: smaller}
  53. span.nocodebreak {white-space:nowrap}
  54. span.nolinebreak {white-space:nowrap}
  55. span.roman {font-family:serif; font-weight:normal}
  56. span.sansserif {font-family:sans-serif; font-weight:normal}
  57. ul.no-bullet {list-style: none}
  58. -->
  59. </style>
  60. </head>
  61. <body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
  62. <a name="Parsing-pass"></a>
  63. <div class="header">
  64. <p>
  65. Next: <a href="Cilk-Plus-Transformation.html#Cilk-Plus-Transformation" accesskey="n" rel="next">Cilk Plus Transformation</a>, Up: <a href="Passes.html#Passes" accesskey="u" rel="up">Passes</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
  66. </div>
  67. <hr>
  68. <a name="Parsing-pass-1"></a>
  69. <h3 class="section">9.1 Parsing pass</h3>
  70. <a name="index-GENERIC"></a>
  71. <a name="index-lang_005fhooks_002eparse_005ffile"></a>
  72. <p>The language front end is invoked only once, via
  73. <code>lang_hooks.parse_file</code>, to parse the entire input. The language
  74. front end may use any intermediate language representation deemed
  75. appropriate. The C front end uses GENERIC trees (see <a href="GENERIC.html#GENERIC">GENERIC</a>), plus
  76. a double handful of language specific tree codes defined in
  77. <samp>c-common.def</samp>. The Fortran front end uses a completely different
  78. private representation.
  79. </p>
  80. <a name="index-GIMPLE"></a>
  81. <a name="index-gimplification"></a>
  82. <a name="index-gimplifier"></a>
  83. <a name="index-language_002dindependent-intermediate-representation"></a>
  84. <a name="index-intermediate-representation-lowering"></a>
  85. <a name="index-lowering_002c-language_002ddependent-intermediate-representation"></a>
  86. <p>At some point the front end must translate the representation used in the
  87. front end to a representation understood by the language-independent
  88. portions of the compiler. Current practice takes one of two forms.
  89. The C front end manually invokes the gimplifier (see <a href="GIMPLE.html#GIMPLE">GIMPLE</a>) on each function,
  90. and uses the gimplifier callbacks to convert the language-specific tree
  91. nodes directly to GIMPLE before passing the function off to be compiled.
  92. The Fortran front end converts from a private representation to GENERIC,
  93. which is later lowered to GIMPLE when the function is compiled. Which
  94. route to choose probably depends on how well GENERIC (plus extensions)
  95. can be made to match up with the source language and necessary parsing
  96. data structures.
  97. </p>
  98. <p>BUG: Gimplification must occur before nested function lowering,
  99. and nested function lowering must be done by the front end before
  100. passing the data off to cgraph.
  101. </p>
  102. <p>TODO: Cgraph should control nested function lowering. It would
  103. only be invoked when it is certain that the outer-most function
  104. is used.
  105. </p>
  106. <p>TODO: Cgraph needs a gimplify_function callback. It should be
  107. invoked when (1) it is certain that the function is used, (2)
  108. warning flags specified by the user require some amount of
  109. compilation in order to honor, (3) the language indicates that
  110. semantic analysis is not complete until gimplification occurs.
  111. Hum&hellip; this sounds overly complicated. Perhaps we should just
  112. have the front end gimplify always; in most cases it&rsquo;s only one
  113. function call.
  114. </p>
  115. <p>The front end needs to pass all function definitions and top level
  116. declarations off to the middle-end so that they can be compiled and
  117. emitted to the object file. For a simple procedural language, it is
  118. usually most convenient to do this as each top level declaration or
  119. definition is seen. There is also a distinction to be made between
  120. generating functional code and generating complete debug information.
  121. The only thing that is absolutely required for functional code is that
  122. function and data <em>definitions</em> be passed to the middle-end. For
  123. complete debug information, function, data and type declarations
  124. should all be passed as well.
  125. </p>
  126. <a name="index-rest_005fof_005fdecl_005fcompilation"></a>
  127. <a name="index-rest_005fof_005ftype_005fcompilation"></a>
  128. <a name="index-cgraph_005ffinalize_005ffunction"></a>
  129. <p>In any case, the front end needs each complete top-level function or
  130. data declaration, and each data definition should be passed to
  131. <code>rest_of_decl_compilation</code>. Each complete type definition should
  132. be passed to <code>rest_of_type_compilation</code>. Each function definition
  133. should be passed to <code>cgraph_finalize_function</code>.
  134. </p>
  135. <p>TODO: I know rest_of_compilation currently has all sorts of
  136. RTL generation semantics. I plan to move all code generation
  137. bits (both Tree and RTL) to compile_function. Should we hide
  138. cgraph from the front ends and move back to rest_of_compilation
  139. as the official interface? Possibly we should rename all three
  140. interfaces such that the names match in some meaningful way and
  141. that is more descriptive than &quot;rest_of&quot;.
  142. </p>
  143. <p>The middle-end will, at its option, emit the function and data
  144. definitions immediately or queue them for later processing.
  145. </p>
  146. <hr>
  147. <div class="header">
  148. <p>
  149. Next: <a href="Cilk-Plus-Transformation.html#Cilk-Plus-Transformation" accesskey="n" rel="next">Cilk Plus Transformation</a>, Up: <a href="Passes.html#Passes" accesskey="u" rel="up">Passes</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
  150. </div>
  151. </body>
  152. </html>