<indexterm><primary>using GHC</primary></indexterm>
<sect1>
+ <title>Getting started: compiling programs</title>
+
+ <para>
+ In this chapter you'll find a complete reference to the GHC
+ command-line syntax, including all 400+ flags. It's a large and
+ complex system, and there are lots of details, so it can be
+ quite hard to figure out how to get started. With that in mind,
+ this introductory section provides a quick introduction to the
+ basic usage of GHC for compiling a Haskell program, before the
+ following sections dive into the full syntax.
+ </para>
+
+ <para>
+ Let's create a Hello World program, and compile and run it.
+ First, create a file <filename>hello.hs</filename> containing
+ the Haskell code:
+ </para>
+
+<programlisting>
+main = putStrLn "Hello, World!"
+</programlisting>
+
+ <para>To compile the program, use GHC like this:</para>
+
+<screen>
+$ ghc hello.hs</screen>
+
+ <para>(where <literal>$</literal> represents the prompt: don't
+ type it). GHC will compile the source
+ file <filename>hello.hs</filename>, producing
+ an <firstterm>object
+ file</firstterm> <filename>hello.o</filename> and
+ an <firstterm>interface
+ file</firstterm> <filename>hello.hi</filename>, and then it
+ will link the object file to the libraries that come with GHC
+ to produce an executable called <filename>hello</filename> on
+ Unix/Linux/Mac, or <filename>hello.exe</filename> on
+ Windows.</para>
+
+ <para>
+ By default GHC will be very quiet about what it is doing, only
+ printing error messages. If you want to see in more detail
+ what's going on behind the scenes, add <option>-v</option> to
+ the command line.
+ </para>
+
+ <para>
+ Then we can run the program like this:
+ </para>
+
+<screen>
+$ ./hello
+Hello World!</screen>
+
+ <para>
+ If your program contains multiple modules, then you only need to
+ tell GHC the name of the source file containing
+ the <filename>Main</filename> module, and GHC will examine
+ the <literal>import</literal> declarations to find the other
+ modules that make up the program and find their source files.
+ This means that, with the exception of
+ the <literal>Main</literal> module, every source file should be
+ named after the module name that it contains (with dots replaced
+ by directory separators). For example, the
+ module <literal>Data.Person</literal> would be in the
+ file <filename>Data/Person.hs</filename> on Unix/Linux/Mac,
+ or <filename>Data\Person.hs</filename> on Windows.
+ </para>
+ </sect1>
+
+ <sect1>
<title>Options overview</title>
-
+
<para>GHC's behaviour is controlled by
<firstterm>options</firstterm>, which for historical reasons are
also sometimes referred to as command-line flags or arguments.
<sect2>
<title>Command-line arguments</title>
-
+
<indexterm><primary>structure, command-line</primary></indexterm>
<indexterm><primary>command-line</primary><secondary>arguments</secondary></indexterm>
<indexterm><primary>arguments</primary><secondary>command-line</secondary></indexterm>
-
+
<para>An invocation of GHC takes the following form:</para>
<screen>
<sect2 id="source-file-options">
<title>Command line options in source files</title>
-
+
<indexterm><primary>source-file options</primary></indexterm>
<para>Sometimes it is useful to make the connection between a
module X where
...
</programlisting>
-
+
<para><literal>OPTIONS_GHC</literal> is a <emphasis>file-header pragma</emphasis>
(see <xref linkend="pragmas"/>).</para>
for more details.</para>
</sect2>
</sect1>
-
+
<sect1 id="static-dynamic-flags">
<title>Static, Dynamic, and Mode options</title>
<indexterm><primary>static</primary><secondary>options</secondary>
<varlistentry>
<term>Mode flags</term>
<listitem>
- <para>For example, <option>--make</option> or <option>-E</option>.
+ <para>For example, <option>––make</option> or <option>-E</option>.
There may only be a single mode flag on the command line. The
available modes are listed in <xref linkend="modes"/>.</para>
</listitem>
</listitem>
</varlistentry>
</variablelist>
-
+
<para>The flag reference tables (<xref
linkend="flag-reference"/>) lists the status of each flag.</para>
<para>There are a few flags that are static except that they can
also be used with GHCi's <literal>:set</literal> command; these
are listed as “static/<literal>:set</literal>” in the
- table.</para>
+ table.</para>
</sect1>
<sect1 id="file-suffixes">
compiler.</para>
</listitem>
</varlistentry>
-
+
+ <varlistentry>
+ <term><filename>.ll</filename></term>
+ <listitem>
+ <para>An llvm-intermediate-language source file, usually
+ produced by the compiler.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><filename>.bc</filename></term>
+ <listitem>
+ <para>An llvm-intermediate-language bitcode file, usually
+ produced by the compiler.</para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term><filename>.s</filename></term>
<listitem>
<sect1 id="modes">
<title>Modes of operation</title>
- <para>GHC's behaviour is firstly controlled by a mode flag. Only
- one of these flags may be given, but it does not necessarily need
- to be the first option on the command-line. The available modes
- are:</para>
+ <para>
+ GHC's behaviour is firstly controlled by a mode flag. Only one
+ of these flags may be given, but it does not necessarily need to
+ be the first option on the command-line.
+ </para>
+
+ <para>
+ If no mode flag is present, then GHC will enter make mode
+ (<xref linkend="make-mode" />) if there are any Haskell source
+ files given on the command line, or else it will link the
+ objects named on the command line to produce an executable.
+ </para>
+
+ <para>The available mode flags are:</para>
<variablelist>
<varlistentry>
more detail in <xref linkend="ghci"/>.</para>
</listitem>
</varlistentry>
-
+
<varlistentry>
<term>
- <cmdsynopsis><command>ghc --make</command>
+ <cmdsynopsis><command>ghc ––make</command>
</cmdsynopsis>
<indexterm><primary>make mode</primary></indexterm>
<indexterm><primary><option>––make</option></primary></indexterm>
likely to be much easier, and faster, than using
<command>make</command>. Make mode is described in <xref
linkend="make-mode"/>.</para>
+
+ <para>
+ This mode is the default if there are any Haskell
+ source files mentioned on the command line, and in this case
+ the <option>––make</option> option can be omitted.
+ </para>
</listitem>
</varlistentry>
more details.</para>
</listitem>
</varlistentry>
-
+
<varlistentry>
<term>
<cmdsynopsis>
<varlistentry>
<term>
<cmdsynopsis>
+ <command>ghc --supported-extensions</command>
<command>ghc --supported-languages</command>
</cmdsynopsis>
- <indexterm><primary><option>––supported-languages</option></primary></indexterm>
+ <indexterm><primary><option>––supported-extensions</option></primary><primary><option>––supported-languages</option></primary></indexterm>
</term>
<listitem>
<para>Print the supported language extensions.</para>
<title>Using <command>ghc</command> <option>––make</option></title>
<indexterm><primary><option>––make</option></primary></indexterm>
<indexterm><primary>separate compilation</primary></indexterm>
-
- <para>When given the <option>––make</option> option,
- GHC will build a multi-module Haskell program by following
+
+ <para>In this mode, GHC will build a multi-module Haskell program by following
dependencies from one or more root modules (usually just
<literal>Main</literal>). For example, if your
<literal>Main</literal> module is in a file called
ghc ––make Main.hs
</screen>
- <para>The command line may contain any number of source file
- names or module names; GHC will figure out all the modules in
- the program by following the imports from these initial modules.
- It will then attempt to compile each module which is out of
- date, and finally, if there is a <literal>Main</literal> module,
- the program will also be linked into an executable.</para>
+ <para>
+ In fact, GHC enters make mode automatically if there are any
+ Haskell source files on the command line and no other mode is
+ specified, so in this case we could just type
+ </para>
+
+<screen>
+ghc Main.hs
+</screen>
+
+ <para>Any number of source file names or module names may be
+ specified; GHC will figure out all the modules in the program by
+ following the imports from these initial modules. It will then
+ attempt to compile each module which is out of date, and
+ finally, if there is a <literal>Main</literal> module, the
+ program will also be linked into an executable.</para>
<para>The main advantages to using <literal>ghc
––make</literal> over traditional
source.</para>
</listitem>
</itemizedlist>
-
+
<para>Any of the command-line options described in the rest of
this chapter can be used with
<option>––make</option>, but note that any options
(say, some auxiliary C code), then the object files can be
given on the command line and GHC will include them when linking
the executable.</para>
-
+
<para>Note that GHC can only follow dependencies if it has the
source file available, so if your program includes a module for
which there is no source file, even if you have an object and an
to add directories to the search path (see <xref
linkend="search-path"/>).</para>
</sect2>
-
+
<sect2 id="eval-mode">
<title>Expression evaluation mode</title>
<screen>
ghc -e Main.main Main.hs
</screen>
-
+
<para>or we can just use this mode to evaluate expressions in
the context of the <literal>Prelude</literal>:</para>
<sect2 id="options-order">
<title>Batch compiler mode</title>
-
+
<para>In <emphasis>batch mode</emphasis>, GHC will compile one or more source files
given on the command line.</para>
-
+
<para>The first phase to run is determined by each input-file
suffix, and the last phase is determined by a flag. If no
relevant flag is present, then go all the way through to linking.
This table summarises:</para>
-
+
<informaltable>
<tgroup cols="4">
<colspec align="left"/>
<colspec align="left"/>
<colspec align="left"/>
<colspec align="left"/>
-
+
<thead>
<row>
<entry>Phase of the compilation system</entry>
<entry>-</entry>
<entry><literal>.hs</literal></entry>
</row>
-
+
<row>
<entry>C pre-processor (opt.) </entry>
<entry><literal>.hs</literal> (with
<entry><option>-E</option></entry>
<entry><literal>.hspp</literal></entry>
</row>
-
+
<row>
<entry>Haskell compiler</entry>
<entry><literal>.hs</literal></entry>
<entry><option>-C</option>, <option>-S</option></entry>
<entry><literal>.hc</literal>, <literal>.s</literal></entry>
</row>
-
+
<row>
<entry>C compiler (opt.)</entry>
<entry><literal>.hc</literal> or <literal>.c</literal></entry>
<entry><option>-S</option></entry>
<entry><literal>.s</literal></entry>
</row>
-
+
<row>
<entry>assembler</entry>
<entry><literal>.s</literal></entry>
<entry><option>-c</option></entry>
<entry><literal>.o</literal></entry>
</row>
-
+
<row>
<entry>linker</entry>
<entry><replaceable>other</replaceable></entry>
</tbody>
</tgroup>
</informaltable>
-
+
<indexterm><primary><option>-C</option></primary></indexterm>
<indexterm><primary><option>-E</option></primary></indexterm>
<indexterm><primary><option>-S</option></primary></indexterm>
<indexterm><primary><option>-c</option></primary></indexterm>
-
+
<para>Thus, a common invocation would be: </para>
<screen>
ghc -c Foo.hs</screen>
-
+
<para>to compile the Haskell source file
<filename>Foo.hs</filename> to an object file
<filename>Foo.o</filename>.</para>
<option>-cpp</option><indexterm><primary><option>-cpp</option></primary></indexterm>
flag turns it on. See <xref linkend="c-pre-processor"/> for more
details.</para>
-
+
<para>Note: The option <option>-E</option><indexterm><primary>-E
option</primary></indexterm> runs just the pre-processing passes
of the compiler, dumping the result in a file.</para>
<variablelist>
<varlistentry>
<term>
- <option>-n</option>
- <indexterm><primary><option>-n</option></primary></indexterm>
- </term>
- <listitem>
- <para>Does a dry-run, i.e. GHC goes through all the motions
- of compiling as normal, but does not actually run any
- external commands.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
<option>-v</option>
<indexterm><primary><option>-v</option></primary></indexterm>
</term>
verify.</para>
</listitem>
</varlistentry>
-
+
<varlistentry>
<term>
<option>-v</option><replaceable>n</replaceable>
argument. Specifying <option>-v</option> on its own is
equivalent to <option>-v3</option>, and the other levels
have the following meanings:</para>
-
+
<variablelist>
<varlistentry>
<term><option>-v0</option></term>
</variablelist>
</listitem>
</varlistentry>
-
+
<varlistentry>
<term><option>-ferror-spans</option>
<indexterm><primary><option>-ferror-spans</option></primary>
suspicious code. The warnings that are
<emphasis>not</emphasis> enabled by <option>-Wall</option>
are
- <option>-fwarn-simple-patterns</option>,
<option>-fwarn-tabs</option>,
+ <option>-fwarn-incomplete-uni-patterns</option>,
<option>-fwarn-incomplete-record-updates</option>,
<option>-fwarn-monomorphism-restriction</option>,
- <option>-fwarn-unused-do-bind</option>, and
+ <option>-fwarn-unrecognised-pragmas</option>,
+ <option>-fwarn-auto-orphans</option>,
<option>-fwarn-implicit-prelude</option>.</para>
</listitem>
</varlistentry>
<term><option>-Werror</option>:</term>
<listitem>
<indexterm><primary><option>-Werror</option></primary></indexterm>
- <para>Makes any warning into a fatal error. Useful so that you don't
+ <para>Makes any warning into a fatal error. Useful so that you don't
miss warnings when doing batch compilation. </para>
</listitem>
</varlistentry>
is bound in a way that looks lazy, e.g.
<literal>where (I# x) = ...</literal>. Use
<literal>where !(I# x) = ...</literal> instead. This will be an
- error, rather than a warning, in GHC 6.14.
+ error, rather than a warning, in GHC 7.2.
</para>
</listitem>
</varlistentry>
</varlistentry>
<varlistentry>
+ <term><option>-fwarn-identities</option>:</term>
+ <listitem>
+ <indexterm><primary><option>-fwarn-identities</option></primary></indexterm>
+ <para>Causes the compiler to emit a warning when a Prelude numeric
+ conversion converts a type T to the same type T; such calls
+ are probably no-ops and can be omitted. The functions checked for
+ are: <literal>toInteger</literal>,
+ <literal>toRational</literal>,
+ <literal>fromIntegral</literal>,
+ and <literal>realToFrac</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>-fwarn-implicit-prelude</option>:</term>
<listitem>
<indexterm><primary><option>-fwarn-implicit-prelude</option></primary></indexterm>
</varlistentry>
<varlistentry>
- <term><option>-fwarn-incomplete-patterns</option>:</term>
+ <term><option>-fwarn-incomplete-patterns</option>,
+ <option>-fwarn-incomplete-uni-patterns</option>:
+ </term>
<listitem>
<indexterm><primary><option>-fwarn-incomplete-patterns</option></primary></indexterm>
+ <indexterm><primary><option>-fwarn-incomplete-uni-patterns</option></primary></indexterm>
<indexterm><primary>incomplete patterns, warning</primary></indexterm>
<indexterm><primary>patterns, incomplete</primary></indexterm>
- <para>Similarly for incomplete patterns, the function
+ <para>The option <option>-fwarn-incomplete-patterns</option> warns
+ about places where
+ a pattern-match might fail at runtime.
+ The function
<function>g</function> below will fail when applied to
non-empty lists, so the compiler will emit a warning about
this when <option>-fwarn-incomplete-patterns</option> is
- enabled.</para>
-
+ enabled.
<programlisting>
g [] = 2
</programlisting>
-
- <para>This option isn't enabled by default because it can be
+ This option isn't enabled by default because it can be
a bit noisy, and it doesn't always indicate a bug in the
program. However, it's generally considered good practice
- to cover all the cases in your functions.</para>
+ to cover all the cases in your functions, and it is switched
+ on by <option>-W</option>.</para>
+
+ <para>The flag <option>-fwarn-incomplete-uni-patterns</option> is
+ similar, except that it
+ applies only to lambda-expressions and pattern bindings, constructs
+ that only allow a single pattern:
+<programlisting>
+h = \[] -> 2
+Just k = f y
+</programlisting>
+ </para>
</listitem>
</varlistentry>
</varlistentry>
<varlistentry>
+ <term>
+ <option>-fwarn-missing-import-lists</option>:
+ <indexterm><primary><option>-fwarn-import-lists</option></primary></indexterm>
+ <indexterm><primary>missing import lists, warning</primary></indexterm>
+ <indexterm><primary>import lists, missing</primary></indexterm>
+ </term>
+ <listitem>
+
+ <para>This flag warns if you use an unqualified
+ <literal>import</literal> declaration
+ that does not explicitly list the entities brought into scope. For
+ example
+ </para>
+<programlisting>
+module M where
+ import X( f )
+ import Y
+ import qualified Z
+ p x = f x x
+</programlisting>
+ <para>
+ The <option>-fwarn-import-lists</option> flag will warn about the import
+ of <literal>Y</literal> but not <literal>X</literal>
+ If module <literal>Y</literal> is later changed to export (say) <literal>f</literal>,
+ then the reference to <literal>f</literal> in <literal>M</literal> will become
+ ambiguous. No warning is produced for the import of <literal>Z</literal>
+ because extending <literal>Z</literal>'s exports would be unlikely to produce
+ ambiguity in <literal>M</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>-fwarn-missing-methods</option>:</term>
<listitem>
<indexterm><primary><option>-fwarn-missing-methods</option></primary></indexterm>
complexFn :: a -> a -> String
complexFn x y = ... _simpleFn ...
</programlisting>
- The idea is that: (a) users of the class will only call <literal>complexFn</literal>;
+ The idea is that: (a) users of the class will only call <literal>complexFn</literal>;
never <literal>_simpleFn</literal>; and (b)
instance declarations can define either <literal>complexFn</literal> or <literal>_simpleFn</literal>.
</para>
</varlistentry>
<varlistentry>
+ <term><option>-fwarn-missing-local-sigs</option>:</term>
+ <listitem>
+ <indexterm><primary><option>-fwarn-missing-local-sigs</option></primary></indexterm>
+ <indexterm><primary>type signatures, missing</primary></indexterm>
+
+ <para>If you use the
+ <option>-fwarn-missing-local-sigs</option> flag GHC will warn
+ you about any polymorphic local bindings. As part of
+ the warning GHC also reports the inferred type. The
+ option is off by default.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>-fwarn-name-shadowing</option>:</term>
<listitem>
<indexterm><primary><option>-fwarn-name-shadowing</option></primary></indexterm>
<indexterm><primary>shadowing, warning</primary></indexterm>
-
+
<para>This option causes a warning to be emitted whenever an
inner-scope value has the same name as an outer-scope value,
i.e. the inner value shadows the outer one. This can catch
<indexterm><primary><option>-fwarn-orphans</option></primary></indexterm>
<indexterm><primary>orphan instances, warning</primary></indexterm>
<indexterm><primary>orphan rules, warning</primary></indexterm>
-
- <para>This option causes a warning to be emitted whenever the
+
+ <para>This option causes a warning to be emitted whenever the
module contains an "orphan" instance declaration or rewrite rule.
An instance declaration is an orphan if it appears in a module in
which neither the class nor the type being instanced are declared
orphans is called an orphan module.</para>
<para>The trouble with orphans is that GHC must pro-actively read the interface
files for all orphan modules, just in case their instances or rules
- play a role, whether or not the module's interface would otherwise
+ play a role, whether or not the module's interface would otherwise
be of any use. See <xref linkend="orphan-modules"/> for details.
</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-fwarn-simple-patterns</option>:</term>
- <listitem>
- <indexterm><primary><option>-fwarn-simple-patterns</option></primary>
- </indexterm>
- <para>Causes the compiler to warn about lambda-bound
- patterns that can fail, eg. <literal>\(x:xs)->...</literal>.
- Normally, these aren't treated as incomplete patterns by
- <option>-fwarn-incomplete-patterns</option>.</para>
- <para>“Lambda-bound patterns” includes all places where there is a single pattern,
- including list comprehensions and do-notation. In these cases, a pattern-match
- failure is quite legitimate, and triggers filtering (list comprehensions) or
- the monad <literal>fail</literal> operation (monads). For example:
- <programlisting>
- f :: [Maybe a] -> [a]
- f xs = [y | Just y <- xs]
- </programlisting>
- Switching on <option>-fwarn-simple-patterns</option> will elicit warnings about
- these probably-innocent cases, which is why the flag is off by default. </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
<term><option>-fwarn-tabs</option>:</term>
<listitem>
<indexterm><primary><option>-fwarn-tabs</option></primary></indexterm>
e.g., the ‘default default’ for Haskell 1.4 caused the
otherwise unconstrained value <constant>1</constant> to be
given the type <literal>Int</literal>, whereas Haskell 98
+ and later
defaults it to <literal>Integer</literal>. This may lead to
differences in performance and behaviour, hence the
usefulness of being non-silent about this.</para>
which are unused. For top-level functions, the warning is
only given if the binding is not exported.</para>
<para>A definition is regarded as "used" if (a) it is exported, or (b) it is
- mentioned in the right hand side of another definition that is used, or (c) the
- function it defines begins with an underscore. The last case provides a
+ mentioned in the right hand side of another definition that is used, or (c) the
+ function it defines begins with an underscore. The last case provides a
way to suppress unused-binding warnings selectively. </para>
<para> Notice that a variable
is reported as unused even if it appears in the right-hand side of another
<indexterm><primary>unused do binding, warning</primary></indexterm>
<indexterm><primary>do binding, unused</primary></indexterm>
- <para>Report expressions occuring in <literal>do</literal> and <literal>mdo</literal> blocks
+ <para>Report expressions occurring in <literal>do</literal> and <literal>mdo</literal> blocks
that appear to silently throw information away.
For instance <literal>do { mapM popInt xs ; return 10 }</literal> would report
the first statement in the <literal>do</literal> block as suspicious,
<indexterm><primary>apparently erroneous do binding, warning</primary></indexterm>
<indexterm><primary>do binding, apparently erroneous</primary></indexterm>
- <para>Report expressions occuring in <literal>do</literal> and <literal>mdo</literal> blocks
+ <para>Report expressions occurring in <literal>do</literal> and <literal>mdo</literal> blocks
that appear to lack a binding.
For instance <literal>do { return (popInt 10) ; return 10 }</literal> would report
the first statement in the <literal>do</literal> block as suspicious,
<option>-O</option>.</para>
</listitem>
</varlistentry>
-
- <varlistentry>
- <term>
- <option>-Ofile <file></option>:
- <indexterm><primary>-Ofile <file> option</primary></indexterm>
- <indexterm><primary>optimising, customised</primary></indexterm>
- </term>
- <listitem>
- <para>(NOTE: not supported since GHC 4.x. Please ask if
- you're interested in this.)</para>
-
- <para>For those who need <emphasis>absolute</emphasis>
- control over <emphasis>exactly</emphasis> what options are
- used (e.g., compiler writers, sometimes :-), a list of
- options can be put in a file and then slurped in with
- <option>-Ofile</option>.</para>
-
- <para>In that file, comments are of the
- <literal>#</literal>-to-end-of-line variety; blank
- lines and most whitespace is ignored.</para>
-
- <para>Please ask if you are baffled and would like an
- example of <option>-Ofile</option>!</para>
- </listitem>
- </varlistentry>
</variablelist>
<para>We don't use a <option>-O*</option> flag for day-to-day
work. We use <option>-O</option> to get respectable speed;
e.g., when we want to measure something. When we want to go for
- broke, we tend to use <option>-O2 -fvia-C</option> (and we go for
+ broke, we tend to use <option>-O2</option> (and we go for
lots of coffee breaks).</para>
<para>The easiest way to see what <option>-O</option> (etc.)
<varlistentry>
<term>
+ <option>-fno-float-in</option>
+ <indexterm><primary><option>-fno-float-in</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Turns off the float-in transformation.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fno-specialise</option>
+ <indexterm><primary><option>-fno-specialise</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Turns off the automatic specialisation of overloaded functions.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
<option>-fspec-constr</option>
<indexterm><primary><option>-fspec-constr</option></primary></indexterm>
</term>
<literal>State#</literal> token as argument is considered to be
single-entry, hence it is considered OK to inline things inside
it. This can improve performance of IO and ST monad code, but it
- runs the risk of reducing sharing.</para>
+ runs the risk of reducing sharing.</para>
</listitem>
</varlistentry>
<indexterm><primary>unfolding, controlling</primary></indexterm>
</term>
<listitem>
- <para>(Default: 45) Governs the maximum size that GHC will
+ <para>(Default: 45) Governs the maximum size that GHC will
allow a function unfolding to be. (An unfolding has a
“size” that reflects the cost in terms of
“code bloat” of expanding that unfolding at
</variablelist>
</sect2>
-
+
</sect1>
-
- &phases;
+
+ &phases;
&shared_libs;
special option or libraries compiled in a certain way. To get access to
the support libraries for Concurrent Haskell, just import
<ulink
- url="../libraries/base/Control-Concurrent.html"><literal>Control.Concurrent</literal></ulink>. More information on Concurrent Haskell is provided in the documentation for that module.</para>
+ url="&libraryBaseLocation;/Control-Concurrent.html"><literal>Control.Concurrent</literal></ulink>. More information on Concurrent Haskell is provided in the documentation for that module.</para>
<para>The following RTS option(s) affect the behaviour of Concurrent
Haskell programs:<indexterm><primary>RTS options, concurrent</primary></indexterm></para>
use GHC to compile and run parallel programs, in <xref
linkend="lang-parallel" /> we describe the language features that affect
parallelism.</para>
-
+
<sect2 id="parallel-compile-options">
<title>Compile-time options for SMP parallelism</title>
linked with the <option>-threaded</option> option (see <xref
linkend="options-linker" />). Additionally, the following
compiler options affect parallelism:</para>
-
+
<variablelist>
<varlistentry>
<term><option>-feager-blackholing</option></term>
results you find.</para></footnote>. For example,
on a dual-core machine we would probably use
<literal>+RTS -N2 -RTS</literal>.</para>
-
+
<para>Omitting <replaceable>x</replaceable>,
i.e. <literal>+RTS -N -RTS</literal>, lets the runtime
choose the value of <replaceable>x</replaceable> itself
<para>There is no means (currently) by which this value
may vary after the program has started.</para>
+
+ <para>The current value of the <option>-N</option> option
+ is available to the Haskell program
+ via <literal>GHC.Conc.numCapabilities</literal>.</para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<varlistentry>
- <term><option>-qm</option></term>
- <indexterm><primary><option>-qm</option></primary><secondary>RTS
+ <term><option>-qa</option></term>
+ <indexterm><primary><option>-qa</option></primary><secondary>RTS
option</secondary></indexterm>
<listitem>
- <para>Disable automatic migration for load balancing.
- Normally the runtime will automatically try to schedule
- threads across the available CPUs to make use of idle
- CPUs; this option disables that behaviour. It is probably
- only of use if you are explicitly scheduling threads onto
- CPUs with <literal>GHC.Conc.forkOnIO</literal>.</para>
+ <para>Use the OS's affinity facilities to try to pin OS
+ threads to CPU cores. This is an experimental feature,
+ and may or may not be useful. Please let us know
+ whether it helps for you!</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-qw</option></term>
- <indexterm><primary><option>-qw</option></primary><secondary>RTS
+ <term><option>-qm</option></term>
+ <indexterm><primary><option>-qm</option></primary><secondary>RTS
option</secondary></indexterm>
<listitem>
- <para>Migrate a thread to the current CPU when it is woken
- up. Normally when a thread is woken up after being
- blocked it will be scheduled on the CPU it was running on
- last; this option allows the thread to immediately migrate
- to the CPU that unblocked it.</para>
-
- <para>The rationale for allowing this eager migration is
- that it tends to move threads that are communicating with
- each other onto the same CPU; however there are
- pathalogical situations where it turns out to be a poor
- strategy. Depending on the communication pattern in your
- program, it may or may not be a good idea.</para>
+ <para>Disable automatic migration for load balancing.
+ Normally the runtime will automatically try to schedule
+ threads across the available CPUs to make use of idle
+ CPUs; this option disables that behaviour. Note that
+ migration only applies to threads; sparks created
+ by <literal>par</literal> are load-balanced separately
+ by work-stealing.</para>
+
+ <para>
+ This option is probably only of use for concurrent
+ programs that explicitly schedule threads onto CPUs
+ with <literal>GHC.Conc.forkOnIO</literal>.
+ </para>
</listitem>
</varlistentry>
</variablelist>
</sect2>
-
+
<sect2>
<title>Hints for using SMP parallelism</title>
whether your program got faster by using more CPUs or not. If the user
time is greater than
the elapsed time, then the program used more than one CPU. You should
- also run the program without <literal>-N</literal> for comparison.</para>
-
- <para>GHC's parallelism support is new and experimental. It may make your
- program go faster, or it might slow it down - either way, we'd be
- interested to hear from you.</para>
-
- <para>One significant limitation with the current implementation is that
- the garbage collector is still single-threaded, and all execution must
- stop when GC takes place. This can be a significant bottleneck in a
- parallel program, especially if your program does a lot of GC. If this
- happens to you, then try reducing the cost of GC by tweaking the GC
- settings (<xref linkend="rts-options-gc" />): enlarging the heap or the
- allocation area size is a good start.</para>
+ also run the program without <literal>-N</literal> for
+ comparison.</para>
+
+ <para>The output of <literal>+RTS -s</literal> tells you how
+ many “sparks” were created and executed during the
+ run of the program (see <xref linkend="rts-options-gc" />), which
+ will give you an idea how well your <literal>par</literal>
+ annotations are working.</para>
+
+ <para>GHC's parallelism support has improved in 6.12.1 as a
+ result of much experimentation and tuning in the runtime
+ system. We'd still be interested to hear how well it works
+ for you, and we're also interested in collecting parallel
+ programs to add to our benchmarking suite.</para>
</sect2>
</sect1>
<variablelist>
<varlistentry>
- <term><option>-monly-[32]-regs</option>:</term>
+ <term><option>-msse2</option>:</term>
<listitem>
- <para>(iX86 machines)<indexterm><primary>-monly-N-regs
- option (iX86 only)</primary></indexterm> GHC tries to
- “steal” four registers from GCC, for performance
- reasons; it almost always works. However, when GCC is
- compiling some modules with four stolen registers, it will
- crash, probably saying:
-
-<screen>
-Foo.hc:533: fixed or forbidden register was spilled.
-This may be due to a compiler bug or to impossible asm
-statements or clauses.
-</screen>
-
- Just give some registers back with
- <option>-monly-N-regs</option>. Try `3' first, then `2'.
- If `2' doesn't work, please report the bug to us.</para>
- </listitem>
+ <para>
+ (x86 only, added in GHC 7.0.1) Use the SSE2 registers and
+ instruction set to implement floating point operations
+ when using the native code generator. This gives a
+ substantial performance improvement for floating point,
+ but the resulting compiled code will only run on
+ processors that support SSE2 (Intel Pentium 4 and later,
+ or AMD Athlon 64 and later).
+ </para>
+ <para>
+ SSE2 is unconditionally used on x86-64 platforms.
+ </para>
+ </listitem>
</varlistentry>
+
</variablelist>
</sect1>
<indexterm><primary>intermediate code generation</primary></indexterm>
- <para>GHC can dump its optimized intermediate code (said to be in “Core” format)
+ <para>GHC can dump its optimized intermediate code (said to be in “Core” format)
to a file as a side-effect of compilation. Non-GHC back-end tools can read and process Core files; these files have the suffix
- <filename>.hcr</filename>. The Core format is described in <ulink url="../ext-core/core.pdf">
- <citetitle>An External Representation for the GHC Core Language</citetitle></ulink>,
+ <filename>.hcr</filename>. The Core format is described in <ulink url="../../core.pdf">
+ <citetitle>An External Representation for the GHC Core Language</citetitle></ulink>,
and sample tools
- for manipulating Core files (in Haskell) are in the GHC source distribution
- directory under <literal>utils/ext-core</literal>.
- Note that the format of <literal>.hcr</literal>
- files is <emphasis>different</emphasis> from the Core output format that GHC generates
+ for manipulating Core files (in Haskell) are available in the
+ <ulink url="http://hackage.haskell.org/package/extcore">extcore package on Hackage</ulink>. Note that the format of <literal>.hcr</literal>
+ files is <emphasis>different</emphasis> from the Core output format that GHC generates
for debugging purposes (<xref linkend="options-debugging"/>), though the two formats appear somewhat similar.</para>
<para>The Core format natively supports notes which you can add to
<!-- Emacs stuff:
;;; Local Variables: ***
- ;;; mode: xml ***
;;; sgml-parent-document: ("users_guide.xml" "book" "chapter") ***
;;; End: ***
-->
projects / ghc-hetmet.git / blobdiff