<a
href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/HsVersions.h"><code>HsVersions.h</code></a>.
+ <h2>What Happens When</h2>
+ <p>
+ Inside the Haskell compiler proper (<code>hsc</code>), a whole series of
+ stages (``passes'') are executed in order to transform your Haskell program
+ into C or native code. This process is orchestrated by
+ <code>main/HscMain.hscMain</code> and its relative
+ <code>hscReComp</code>. The latter directly invokes, in order,
+ the parser, the renamer, the typechecker, the desugarer, the
+ simplifier (Core2Core), the CoreTidy pass, the CorePrep pass,
+ conversion to STG (CoreToStg), the interface generator
+ (MkFinalIface), the code generator, and code output. The
+ simplifier is the most complex of these, and is made up of many
+ sub-passes. These are controlled by <code>buildCoreToDo</code>,
+ as described below.
+
+ <h2>Scheduling Optimisations Phases</h2>
+ <p>
+ GHC has a large variety of optimisations at its disposal, many of which
+ have subtle interdependencies. The overall plan for program
+ optimisation is fixed in <a
+ href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/DriverState.hs"><code>DriverState.hs</code></a>.
+ First of all, there is the variable <code>hsc_minusNoO_flags</code> that
+ determines the <code>-f</code> options that you get without
+ <code>-O</code> (aka optimisation level 0) as well as
+ <code>hsc_minusO_flags</code> and <code>hsc_minusO2_flags</code> for
+ <code>-O</code> and <code>-O2</code>.
+ <p>
+ However, most of the strategic decisions about optimisations on the
+ intermediate language Core are encoded in the value produced by
+ <code>buildCoreToDo</code>, which is a list with elements of type
+ <code>CoreToDo</code>. Each element of this list specifies one step in
+ the sequence of core optimisations executed by the <a
+ href="simplifier.html">Mighty Simplifier</a>. The type
+ <code>CoreToDo</code> is defined in <a
+ href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/CmdLineOpts.lhs"><code>CmdLineOpts.lhs</code></a>.
+ The actual execution of the optimisation plan produced by
+ <code>buildCoreToDo</code> is performed by <a
+ href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/simplCore/SimplCore.lhs"><code>SimpleCore</code></a><code>.doCorePasses</code>.
+ Core optimisation plans consist of a number of simplification phases
+ (currently, three for optimisation levels of 1 or higher) with
+ decreasing phase numbers (the lowest, corresponding to the last phase,
+ namely 0). Before and after these phases, optimisations such as
+ specialisation, let floating, worker/wrapper, and so on are executed.
+ The sequence of phases is such that the synergistic effect of the phases
+ is maximised -- however, this is a fairly fragile arrangement.
+ <p>
+ There is a similar construction for optimisations on STG level stored in
+ the variable <code>buildStgToDo :: [StgToDo]</code>. However, this is a
+ lot less complex than the arrangement for Core optimisations.
+
<h2>Linking the <code>RTS</code> and <code>libHSstd</code></h2>
<p>
Since the RTS and HSstd refer to each other, there is a Cunning
adding
the symbols that the RTS needs from libHSstd, such as
<code>PrelWeak_runFinalizzerBatch_closure</code> and
- <code>__init_Prelude</code>, to the link line with the
+ <code>__stginit_Prelude</code>, to the link line with the
<code>-u</code> flag. The standard library appears before the
RTS on the link line, and these options cause the corresponding
symbols to be picked up even so the linked might not have seen them
supplied by the RTS (in the file
<a href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/rts/Main.c"><code>Main.c</code></a>).
It calls <code>startupHaskell</code>, which
- itself calls <code>__init_PrelMain</code>, which is therefore,
+ itself calls <code>__stginit_PrelMain</code>, which is therefore,
since it occurs in the standard library, one of the symbols
passed to the linker using the <code>-u</code> option. This is fine
for standalone Haskell programs, but as soon as the Haskell code is only
<code>main()</code> function of that foreign language should be used
instead of that of the Haskell runtime. In this case, the previously
described arrangement unfortunately fails as
- <code>__init_PrelMain</code> had better not be linked in,
- because it tries to call <code>__init_Main</code>, which won't
+ <code>__stginit_PrelMain</code> had better not be linked in,
+ because it tries to call <code>__stginit_Main</code>, which won't
exist. In other words, the RTS's <code>main()</code> refers to
- <code>__init_PrelMain</code> which in turn refers to
- <code>__init_Main</code>. Although the RTS's <code>main()</code>
+ <code>__stginit_PrelMain</code> which in turn refers to
+ <code>__stginit_Main</code>. Although the RTS's <code>main()</code>
might not be linked in if the program provides its own, the driver
- will normally force <code>__init_PrelMain</code> to be linked in anyway,
+ will normally force <code>__stginit_PrelMain</code> to be linked in anyway,
using <code>-u</code>, because it's a back-reference from the
RTS to HSstd. This case is coped with by the <code>-no-hs-main</code>
flag, which suppresses passing the corresonding <code>-u</code> option
it didn't work. In addition, the driver generally places the C program
providing the <code>main()</code> that we want to use before the RTS
on the link line. Therefore, the RTS's main is never used and
- without the <code>-u</code> the label <code>__init_PrelMain</code>
+ without the <code>-u</code> the label <code>__stginit_PrelMain</code>
will not be linked.
</p>
<p><small>
<!-- hhmts start -->
-Last modified: Fri Aug 24 23:12:33 EST 2001
+Last modified: Tue Feb 19 11:09:00 UTC 2002
<!-- hhmts end -->
</small>
</body>
projects / ghc-hetmet.git / blobdiff