1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
4 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
5 <title>The GHC Commentary - The Evil Mangler</title>
8 <body BGCOLOR="FFFFFF">
9 <h1>The GHC Commentary - The Evil Mangler</h1>
11 The Evil Mangler (EM) is a Perl script invoked by the <a
12 href="driver.html">Glorious Driver</a> after the C compiler (gcc) has
13 translated the GHC-produced C code into assembly. Consequently, it is
14 only of interest if <code>-fvia-C</code> is in effect (either explicitly
19 The EM reads the assembly produced by gcc and re-arranges code blocks as
20 well as nukes instructions that it considers <em>non-essential.</em> It
21 derives it evilness from its utterly ad hoc, machine, compiler, and
22 whatnot dependent design and implementation. More precisely, the EM
23 performs the following tasks:
25 <li>The code executed when a closure is entered is moved adjacent to
26 that closure's infotable. Moreover, the order of the info table
27 entries is reversed. Also, SRT pointers are removed from closures that
28 don't need them (non-FUN, RET and THUNK ones).
29 <li>Function prologue and epilogue code is removed. (GHC generated code
30 manages its own stack and uses the system stack only for return
31 addresses and during calls to C code.)
32 <li>Certain code patterns are replaced by simpler code (eg, loads of
33 fast entry points followed by indirect jumps are replaced by direct
34 jumps to the fast entry point).
37 <h4>Implementation</h4>
39 The EM is located in the Perl script <a
40 href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/driver/mangler/ghc-asm.lprl"><code>ghc-asm.lprl</code></a>.
41 The script reads the <code>.s</code> file and chops it up into
42 <em>chunks</em> (that's how they are actually called in the script) that
43 roughly correspond to basic blocks. Each chunk is annotated with an
44 educated guess about what kind of code it contains (e.g., infotable,
45 fast entry point, slow entry point, etc.). The annotations also contain
46 the symbol introducing the chunk of assembly and whether that chunk has
47 already been processed or not.
49 The parsing of the input into chunks as well as recognising assembly
50 instructions that are to be removed or altered is based on a large
51 number of Perl regular expressions sprinkled over the whole code. These
52 expressions are rather fragile as they heavily rely on the structure of
53 the generated code - in fact, they even rely on the right amount of
54 white space and thus on the formatting of the assembly.
56 Afterwards, the chunks are reordered, some of them purged, and some
57 stripped of some useless instructions. Moreover, some instructions are
58 manipulated (eg, loads of fast entry points followed by indirect jumps
59 are replaced by direct jumps to the fast entry point).
61 The EM knows which part of the code belongs to function prologues and
62 epilogues as <a href="../rts-libs/stgc.html">STG C</a> adds tags of the
63 form <code>--- BEGIN ---</code> and <code>--- END ---</code> the
64 assembler just before and after the code proper of a function starts.
65 It adds these tags using gcc's <code>__asm__</code> feature.
67 <strong>Update:</strong> Gcc 2.96 upwards performs more aggressive basic
68 block re-ordering and dead code elimination. This seems to make the
69 whole <code>--- END ---</code> tag business redundant -- in fact, if
70 proper code is generated, no <code>--- END ---</code> tags survive gcc
75 Last modified: Sun Feb 17 17:55:47 EST 2002