Test Trac #9036
[ghc.git] / docs / comm / the-beast / driver.html
1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
2 <html>
3 <head>
4 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
5 <title>The GHC Commentary - The Glorious Driver</title>
6 </head>
7
8 <body BGCOLOR="FFFFFF">
9 <h1>The GHC Commentary - The Glorious Driver</h1>
10 <p>
11 The Glorious Driver (GD) is the part of GHC that orchestrates the
12 interaction of all the other pieces that make up GHC. It supersedes the
13 <em>Evil Driver (ED),</em> which was a Perl script that served the same
14 purpose and was in use until version 4.08.1 of GHC. Simon Marlow
15 eventually slayed the ED and instated the GD. The GD is usually called
16 the <em>Compilation Manager</em> these days.
17 </p>
18 <p>
19 The GD has been substantially extended for GHCi, i.e., the interactive
20 variant of GHC that integrates the compiler with a (meta-circular)
21 interpreter since version 5.00. Most of the driver is located in the
22 directory
23 <a
24 href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/"><code>fptools/ghc/compiler/main/</code></a>.
25 </p>
26
27 <h2>Command Line Options</h2>
28 <p>
29 GHC's many flavours of command line options make the code interpreting
30 them rather involved. The following provides a brief overview of the
31 processing of these options. Since the addition of the interactive
32 front-end to GHC, there are two kinds of options: <em>static
33 options</em> and <em>dynamic options.</em> The former can only be set
34 when the system is invoked, whereas the latter can be altered in the
35 course of an interactive session. A brief explanation on the difference
36 between these options and related matters is at the start of the module
37 <a
38 href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/CmdLineOpts.lhs"><code>CmdLineOpts</code></a>.
39 The same module defines the enumeration <code>DynFlag</code>, which
40 contains all dynamic flags. Moreover, there is the labelled record
41 <code>DynFlags</code> that collects all the flag-related information
42 that is passed by the compilation manager to the compiler proper,
43 <code>hsc</code>, whenever a compilation is triggered. If you like to
44 find out whether an option is static, use the predicate
45 <code>isStaticHscFlag</code> in the same module.
46 <p>
47 The second module that contains a lot of code related to the management
48 of flags is <a
49 href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/DriverFlags.hs"><code>DriverFlags.hs</code></a>.
50 In particular, the module contains two association lists that map the
51 textual representation of the various flags to a data structure that
52 tells the driver how to parse the flag (e.g., whether it has any
53 arguments) and provides its internal representation. All static flags
54 are contained in <code>static_flags</code>. A whole range of
55 <code>-f</code> flags can be negated by adding a <code>-f-no-</code>
56 prefix. These flags are contained in the association list
57 <code>fFlags</code>.
58 <p>
59 The driver uses a nasty hack based on <code>IORef</code>s that permits
60 the rest of the compiler to access static flags as CAFs; i.e., there is
61 a family of toplevel variable definitions in
62 <a
63 href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/CmdLineOpts.lhs"><code>CmdLineOpts</code></a>,
64 below the literate section heading <i>Static options</i>, each of which
65 contains the value of one static option. This is essentially realised
66 via global variables (in the sense of C-style, updatable, global
67 variables) defined via an evil pre-processor macro named
68 <code>GLOBAL_VAR</code>, which is defined in a particularly ugly corner
69 of GHC, namely the C header file
70 <a
71 href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/HsVersions.h"><code>HsVersions.h</code></a>.
72
73 <h2>What Happens When</h2>
74 <p>
75 Inside the Haskell compiler proper (<code>hsc</code>), a whole series of
76 stages (``passes'') are executed in order to transform your Haskell program
77 into C or native code. This process is orchestrated by
78 <code>main/HscMain.hscMain</code> and its relative
79 <code>hscReComp</code>. The latter directly invokes, in order,
80 the parser, the renamer, the typechecker, the desugarer, the
81 simplifier (Core2Core), the CoreTidy pass, the CorePrep pass,
82 conversion to STG (CoreToStg), the interface generator
83 (MkFinalIface), the code generator, and code output. The
84 simplifier is the most complex of these, and is made up of many
85 sub-passes. These are controlled by <code>buildCoreToDo</code>,
86 as described below.
87
88 <h2>Scheduling Optimisations Phases</h2>
89 <p>
90 GHC has a large variety of optimisations at its disposal, many of which
91 have subtle interdependencies. The overall plan for program
92 optimisation is fixed in <a
93 href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/DriverState.hs"><code>DriverState.hs</code></a>.
94 First of all, there is the variable <code>hsc_minusNoO_flags</code> that
95 determines the <code>-f</code> options that you get without
96 <code>-O</code> (aka optimisation level 0) as well as
97 <code>hsc_minusO_flags</code> and <code>hsc_minusO2_flags</code> for
98 <code>-O</code> and <code>-O2</code>.
99 <p>
100 However, most of the strategic decisions about optimisations on the
101 intermediate language Core are encoded in the value produced by
102 <code>buildCoreToDo</code>, which is a list with elements of type
103 <code>CoreToDo</code>. Each element of this list specifies one step in
104 the sequence of core optimisations executed by the <a
105 href="simplifier.html">Mighty Simplifier</a>. The type
106 <code>CoreToDo</code> is defined in <a
107 href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/CmdLineOpts.lhs"><code>CmdLineOpts.lhs</code></a>.
108 The actual execution of the optimisation plan produced by
109 <code>buildCoreToDo</code> is performed by <a
110 href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/simplCore/SimplCore.lhs"><code>SimpleCore</code></a><code>.doCorePasses</code>.
111 Core optimisation plans consist of a number of simplification phases
112 (currently, three for optimisation levels of 1 or higher) with
113 decreasing phase numbers (the lowest, corresponding to the last phase,
114 namely 0). Before and after these phases, optimisations such as
115 specialisation, let floating, worker/wrapper, and so on are executed.
116 The sequence of phases is such that the synergistic effect of the phases
117 is maximised -- however, this is a fairly fragile arrangement.
118 <p>
119 There is a similar construction for optimisations on STG level stored in
120 the variable <code>buildStgToDo :: [StgToDo]</code>. However, this is a
121 lot less complex than the arrangement for Core optimisations.
122
123 <h2>Linking the <code>RTS</code> and <code>libHSstd</code></h2>
124 <p>
125 Since the RTS and HSstd refer to each other, there is a Cunning
126 Hack to avoid putting them each on the command-line twice or
127 thrice (aside: try asking for `plaice and chips thrice' in a
128 fish and chip shop; bet you only get two lots). The hack involves
129 adding
130 the symbols that the RTS needs from libHSstd, such as
131 <code>PrelWeak_runFinalizzerBatch_closure</code> and
132 <code>__stginit_Prelude</code>, to the link line with the
133 <code>-u</code> flag. The standard library appears before the
134 RTS on the link line, and these options cause the corresponding
135 symbols to be picked up even so the linked might not have seen them
136 being used as the RTS appears later on the link line. As a result,
137 when the RTS is also scanned, these symbols are already resolved. This
138 avoids the linker having to read the standard library and RTS
139 multiple times.
140 </p>
141 <p>
142 This does, however, leads to a complication. Normal Haskell
143 programs do not have a <code>main()</code> function, so this is
144 supplied by the RTS (in the file
145 <a href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/rts/Main.c"><code>Main.c</code></a>).
146 It calls <code>startupHaskell</code>, which
147 itself calls <code>__stginit_PrelMain</code>, which is therefore,
148 since it occurs in the standard library, one of the symbols
149 passed to the linker using the <code>-u</code> option. This is fine
150 for standalone Haskell programs, but as soon as the Haskell code is only
151 used as part of a program implemented in a foreign language, the
152 <code>main()</code> function of that foreign language should be used
153 instead of that of the Haskell runtime. In this case, the previously
154 described arrangement unfortunately fails as
155 <code>__stginit_PrelMain</code> had better not be linked in,
156 because it tries to call <code>__stginit_Main</code>, which won't
157 exist. In other words, the RTS's <code>main()</code> refers to
158 <code>__stginit_PrelMain</code> which in turn refers to
159 <code>__stginit_Main</code>. Although the RTS's <code>main()</code>
160 might not be linked in if the program provides its own, the driver
161 will normally force <code>__stginit_PrelMain</code> to be linked in anyway,
162 using <code>-u</code>, because it's a back-reference from the
163 RTS to HSstd. This case is coped with by the <code>-no-hs-main</code>
164 flag, which suppresses passing the corresonding <code>-u</code> option
165 to the linker -- although in some versions of the compiler (e.g., 5.00.2)
166 it didn't work. In addition, the driver generally places the C program
167 providing the <code>main()</code> that we want to use before the RTS
168 on the link line. Therefore, the RTS's main is never used and
169 without the <code>-u</code> the label <code>__stginit_PrelMain</code>
170 will not be linked.
171 </p>
172
173 <p><small>
174 <!-- hhmts start -->
175 Last modified: Tue Feb 19 11:09:00 UTC 2002
176 <!-- hhmts end -->
177 </small>
178 </body>
179 </html>