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