[project @ 2001-06-27 16:38:17 by simonmar]

[ghc-hetmet.git] / ghc / docs / users_guide / sooner.sgml

diff --git a/ghc/docs/users_guide/sooner.sgml b/ghc/docs/users_guide/sooner.sgml
index e7cae66..07a4e4b 100644 (file)
--- a/ghc/docs/users_guide/sooner.sgml
+++ b/ghc/docs/users_guide/sooner.sgml
@@ -33,10 +33,10 @@ GHC is surprisingly zippy for normal compilations without <Option>-O</Option>!
 <ListItem>
 <Para>
 Within reason, more memory for heap space means less garbage
-collection for GHC, which means less compilation time.  If you use
-the <Option>-Rgc-stats</Option> option, you'll get a garbage-collector report.
-(Again, you can use the cheap-and-nasty <Option>-optCrts-Sstderr</Option> option to
-send the GC stats straight to standard error.)
+collection for GHC, which means less compilation time.  If you use the
+<Option>-Rghc-timing</Option> option, you'll get a garbage-collector
+report.  (Again, you can use the cheap-and-nasty <Option>+RTS -Sstderr
+-RTS</Option> option to send the GC stats straight to standard error.)
 </Para>
 
 <Para>
@@ -128,8 +128,8 @@ individually with <Option>-fno-strictness</Option>.
 
 <Para>
 To figure out which part of the compiler is badly behaved, the
-<Option>-dshow-passes</Option><IndexTerm><Primary>-dshow-passes option</Primary></IndexTerm> option is your
-friend.
+<option>-v2</option><indexterm><primary><option>-v</option></primary>
+</indexterm> option is your friend.
 </Para>
 
 <Para>
@@ -141,19 +141,14 @@ allocator to founder.  Bring on <Option>-fvia-C</Option><IndexTerm><Primary>-fvi
 </ListItem>
 </VarListEntry>
 <VarListEntry>
-<Term>Avoid the consistency-check on linking:</Term>
-<ListItem>
-<Para>
-Use <Option>-no-link-chk</Option><IndexTerm><Primary>-no-link-chk</Primary></IndexTerm>; saves effort.  This is
-probably safe in a I-only-compile-things-one-way setup.
-</Para>
-</ListItem>
-</VarListEntry>
-<VarListEntry>
 <Term>Explicit <Literal>import</Literal> declarations:</Term>
 <ListItem>
 <Para>
-Instead of saying <Literal>import Foo</Literal>, say <Literal>import Foo (...stuff I want...)</Literal>.
+Instead of saying <Literal>import Foo</Literal>, say <Literal>import
+Foo (...stuff I want...)</Literal> You can get GHC to tell you the
+minimal set of required imports by using the
+<option>-ddump-minimal-imports</option> option (see <xref
+linkend="hi-options">).
 </Para>
 
 <Para>
@@ -227,12 +222,12 @@ At present, <Option>-O2</Option> is nearly indistinguishable from <Option>-O</Op
 <Term>Compile via C and crank up GCC:</Term>
 <ListItem>
 <Para>
-Even with <Option>-O</Option>, GHC tries to
-use a native-code generator, if available.  But the native
-code-generator is designed to be quick, not mind-bogglingly clever.
-Better to let GCC have a go, as it tries much harder on register
-allocation, etc.
-</Para>
+The native code-generator is designed to be quick, not mind-bogglingly
+clever.  Better to let GCC have a go, as it tries much harder on
+register allocation, etc.</para>
+
+<para>At the moment, if you turn on <option>-O</option> you get GCC
+instead.  This may change in the future.</para>
 
 <Para>
 So, when we want very fast code, we use: <Option>-O -fvia-C -O2-for-C</Option>.
@@ -375,11 +370,14 @@ Don't guess&mdash;look it up.
 
 <Para>
 Look for your function in the interface file, then for the third field
-in the pragma; it should say <Literal>&lowbar;S&lowbar; &lt;string&gt;</Literal>.  The <Literal>&lt;string&gt;</Literal>
-gives the strictness of the function's arguments.  <Function>L</Function> is lazy
-(bad), <Function>S</Function> and <Function>E</Function> are strict (good), <Function>P</Function> is &ldquo;primitive&rdquo; (good),
-<Function>U(...)</Function> is strict and
-&ldquo;unpackable&rdquo; (very good), and <Function>A</Function> is absent (very good).
+in the pragma; it should say <Literal>&lowbar;&lowbar;S
+&lt;string&gt;</Literal>.  The <Literal>&lt;string&gt;</Literal> gives
+the strictness of the function's arguments.  <Function>L</Function> is
+lazy (bad), <Function>S</Function> and <Function>E</Function> are
+strict (good), <Function>P</Function> is &ldquo;primitive&rdquo;
+(good), <Function>U(...)</Function> is strict and
+&ldquo;unpackable&rdquo; (very good), and <Function>A</Function> is
+absent (very good).
 </Para>
 
 <Para>
@@ -453,7 +451,7 @@ types.
 </ListItem>
 </VarListEntry>
 <VarListEntry>
-<Term>Use <Function>&lowbar;ccall&lowbar;s</Function> (a GHC extension) to plug into fast libraries:</Term>
+<Term>Use <Literal>foreign import</Literal> (a GHC extension) to plug into fast libraries:</Term>
 <ListItem>
 <Para>
 This may take real work, but&hellip; There exist piles of
@@ -462,7 +460,7 @@ to compete with it, but link with it.
 </Para>
 
 <Para>
-<XRef LinkEnd="glasgow-ccalls"> says a little about how to use C calls.
+<XRef LinkEnd="sec-ffi"> describes the foreign calling interface.
 </Para>
 </ListItem>
 </VarListEntry>
@@ -522,7 +520,7 @@ Decrease the &ldquo;go-for-it&rdquo; threshold for unfolding smallish
 expressions.  Give a
 <Option>-funfolding-use-threshold0</Option><IndexTerm><Primary>-funfolding-use-threshold0
 option</Primary></IndexTerm> option for the extreme case. (&ldquo;Only unfoldings with
-zero cost should proceed.&rdquo;)  Warning: except in certain specialiised
+zero cost should proceed.&rdquo;)  Warning: except in certain specialised
 cases (like Happy parsers) this is likely to actually
 <Emphasis>increase</Emphasis> the size of your program, because unfolding
 generally enables extra simplifying optimisations to be performed.
@@ -575,3 +573,10 @@ be required).
 </Sect1>
 
 </Chapter>
+
+<!-- Emacs stuff:
+     ;;; Local Variables: ***
+     ;;; mode: sgml ***
+     ;;; sgml-parent-document: ("users_guide.sgml" "book" "chapter") ***
+     ;;; End: ***
+ -->