Commit 11d8ff45 authored by Tobias Dammers's avatar Tobias Dammers 🦈

Fix links to GHC source code

parent 3e8a3d2a
......@@ -47,7 +47,7 @@ G |-co t1 ==>!_R t2 : t1 ~R k2 t2
**SPJ** Actually it should be *unboxed* not *unlifted*. It's wrong to cast between `Array# Int` and `Int#` because the former is a pointer and the latter is not.
1. If types are unlifted then their *size* should be equal, see `primRepSizeW` in [source:compiler/types/TyCon.hs](/trac/ghc/browser/compiler/types/TyCon.hs)[](/trac/ghc/export/HEAD/ghc/compiler/types/TyCon.hs)
1. If types are unlifted then their *size* should be equal, see `primRepSizeW` in [source:compiler/types/TyCon.hs](/ghc/ghc/tree/master/compiler/types/TyCon.hs)[](/trac/ghc/export/HEAD/ghc/compiler/types/TyCon.hs)
1. If types are unlifted then they either should be both floating or both integral. Reason: on many architectures, floating point values are held in special registers.
......@@ -130,7 +130,7 @@ GHC has 2 different sizes: word aligned size of values, and active size in bytes
Term 'active size' is used to describe number of bytes that value actually use, at this moment such numbers are used
in Vectors, see `primElemRepSizeB` in ([source:compiler/types/TyCon.hs](/trac/ghc/browser/compiler/types/TyCon.hs)[](/trac/ghc/export/HEAD/ghc/compiler/types/TyCon.hs)). The reasons about forbidding coercions between
in Vectors, see `primElemRepSizeB` in ([source:compiler/types/TyCon.hs](/ghc/ghc/tree/master/compiler/types/TyCon.hs)[](/trac/ghc/export/HEAD/ghc/compiler/types/TyCon.hs)). The reasons about forbidding coercions between
values with a different active size is that in the rest bytes there will be garbage:
......
......@@ -32,7 +32,7 @@ currently being attempted; see [Building/Shake](building/shake) for more details
The following are a few of the most important files in the build system. For a more complete overview of the source-tree layout, see [Commentary/SourceTree](commentary/source-tree).
<table><tr><th>[ghc.mk](/trac/ghc/browser/ghc/ghc.mk)[](/trac/ghc/export/HEAD/ghc/ghc.mk)</th>
<table><tr><th>[ghc.mk](/ghc/ghc/tree/master/ghc/ghc.mk)[](/trac/ghc/export/HEAD/ghc/ghc.mk)</th>
<td>
This is where you should start reading: `ghc.mk` is the main file in
the build system which ties together all the other build-system
......@@ -41,7 +41,7 @@ files in `mk/*.mk`, `rules/*.mk`, and all the other `ghc.mk` files
elsewhere in the tree.
</td></tr></table>
<table><tr><th>[Makefile](/trac/ghc/browser/ghc/Makefile)[](/trac/ghc/export/HEAD/ghc/Makefile)</th>
<table><tr><th>[Makefile](/ghc/ghc/tree/master/ghc/Makefile)[](/trac/ghc/export/HEAD/ghc/Makefile)</th>
<td>
The top-level `Makefile`, recursively invokes `make` on `ghc.mk`
according to the [phase ordering idiom](building/architecture/idiom/phase-ordering).
......@@ -55,7 +55,7 @@ expression. For example, the `build-package` macro is in
`rules/build-package.mk`.
</td></tr></table>
<table><tr><th>[mk/config.mk.in](/trac/ghc/browser/mk/config.mk.in)[](/trac/ghc/export/HEAD/ghc/mk/config.mk.in)</th>
<table><tr><th>[mk/config.mk.in](/ghc/ghc/tree/master/mk/config.mk.in)[](/trac/ghc/export/HEAD/ghc/mk/config.mk.in)</th>
<td>
The configuration information for the build system, processed by
`configure` to produce `mk/config.mk`. Settings can be overriden by
......@@ -63,7 +63,7 @@ creating a local file `mk/build.mk` (see
[Build configuration](building/using#build-configuration)).
</td></tr></table>
<table><tr><th>[compiler/ghc.mk](/trac/ghc/browser/compiler/ghc.mk)[](/trac/ghc/export/HEAD/ghc/compiler/ghc.mk), [rts/ghc.mk](/trac/ghc/browser/rts/ghc.mk)[](/trac/ghc/export/HEAD/ghc/rts/ghc.mk), etc.</th>
<table><tr><th>[compiler/ghc.mk](/ghc/ghc/tree/master/compiler/ghc.mk)[](/trac/ghc/export/HEAD/ghc/compiler/ghc.mk), [rts/ghc.mk](/trac/ghc/browser/rts/ghc.mk)[](/trac/ghc/export/HEAD/ghc/rts/ghc.mk), etc.</th>
<td>
Most subdirectories of the source tree have a `ghc.mk` file which
contains the instructions for building the components in that
......
......@@ -159,5 +159,5 @@ In the GHC build system, we have 3 phases. Each phase is in two halves: some thi
- Builds: Everything else.
See the comments in the [top-level ghc.mk](/trac/ghc/browser/ghc.mk)[](/trac/ghc/export/HEAD/ghc/ghc.mk) for details
See the comments in the [top-level ghc.mk](/ghc/ghc/tree/master/ghc.mk)[](/trac/ghc/export/HEAD/ghc/ghc.mk) for details
(search for 'Approximate build order' and 'Numbered phase targets').
......@@ -21,7 +21,7 @@ These platforms are set when running the
`configure` script, using the
`--build`, `--host`, and
`--target` options. The `mk/project.mk`
file, which is generated by `configure` from [mk/project.mk.in](/trac/ghc/browser/mk/project.mk.in)[](/trac/ghc/export/HEAD/ghc/mk/project.mk.in), defines several symbols related to the platform settings.
file, which is generated by `configure` from [mk/project.mk.in](/ghc/ghc/tree/master/mk/project.mk.in)[](/trac/ghc/export/HEAD/ghc/mk/project.mk.in), defines several symbols related to the platform settings.
We don't currently support build and host being different, because
......@@ -36,4 +36,4 @@ There is another option, which is similar in essence, namely creating a portable
More details on when to use BUILD, HOST or TARGET can be found in
the comments in [mk/project.mk.in](/trac/ghc/browser/mk/project.mk.in)[](/trac/ghc/export/HEAD/ghc/mk/project.mk.in).
the comments in [mk/project.mk.in](/ghc/ghc/tree/master/mk/project.mk.in)[](/trac/ghc/export/HEAD/ghc/mk/project.mk.in).
......@@ -20,4 +20,4 @@ See also [Idiom: macros](building/architecture/idiom/macros) where many applicat
## Variables affecting compilation
The file [rules/distdir-way-opts.mk](/trac/ghc/browser/ghc/rules/distdir-way-opts.mk) contains a list of the variables affecting compilation, such as `$1_$2_HC_OPTS` and `$1_$2_MORE_HC_OPTS`.
The file [rules/distdir-way-opts.mk](/ghc/ghc/tree/master/ghc/rules/distdir-way-opts.mk) contains a list of the variables affecting compilation, such as `$1_$2_HC_OPTS` and `$1_$2_MORE_HC_OPTS`.
......@@ -90,7 +90,7 @@ Where the documentation is installed.
On Unix systems you can change `libdir` and `bindir` using the `--libdir` and `--bindir` options respectively, and the location of the documentation can be changed using `--datadir`. On Windows all you can do is change `$(prefix)`, because GHC finds the rest of its files by knowing their location relative to the `ghc.exe` binary, so the layout of the install tree is fixed (see [How GHC finds its files](building/installing#how-ghc-finds-its-files), below).
To see how the install directories are derived from `$(prefix)`, look in [mk/install.mk.in](/trac/ghc/browser/mk/install.mk.in)[](/trac/ghc/export/HEAD/ghc/mk/install.mk.in).
To see how the install directories are derived from `$(prefix)`, look in [mk/install.mk.in](/ghc/ghc/tree/master/mk/install.mk.in)[](/trac/ghc/export/HEAD/ghc/mk/install.mk.in).
## DESTDIR
......
......@@ -46,7 +46,7 @@ same as `make show`, but works right after ./configure (it skips reading package
<table><tr><th>`make TRACE=1`</th>
<td>
prints messages about certain macros that are called and their arguments. This is basically a system of `$(warning)` calls enabled when the value of `$(TRACE)` is non-empty. To see how it works, look at the file [rules/trace.mk](/trac/ghc/browser/rules/trace.mk)[](/trac/ghc/export/HEAD/ghc/rules/trace.mk), and feel free to add trace calls to more places in the build system.
prints messages about certain macros that are called and their arguments. This is basically a system of `$(warning)` calls enabled when the value of `$(TRACE)` is non-empty. To see how it works, look at the file [rules/trace.mk](/ghc/ghc/tree/master/rules/trace.mk)[](/trac/ghc/export/HEAD/ghc/rules/trace.mk), and feel free to add trace calls to more places in the build system.
</td></tr></table>
<table><tr><th>`make --debug=b --debug=m`</th>
......@@ -78,12 +78,12 @@ GHC is in two parts:
- the `ghc` program itself, consists of a single `Main` module that imports the `ghc` package. It is found in the `ghc` directory.
Like any Cabal package, the `ghc` package has a `ghc.cabal` file, except that in this case the file is preprocessed by `configure` from the original: [compiler/ghc.cabal.in](/trac/ghc/browser/compiler/ghc.cabal.in)[](/trac/ghc/export/HEAD/ghc/compiler/ghc.cabal.in). Be careful not to modify the preprocessed version, `ghc.cabal`, as it will be overwritten next time you run `configure`.
Like any Cabal package, the `ghc` package has a `ghc.cabal` file, except that in this case the file is preprocessed by `configure` from the original: [compiler/ghc.cabal.in](/ghc/ghc/tree/master/compiler/ghc.cabal.in)[](/trac/ghc/export/HEAD/ghc/compiler/ghc.cabal.in). Be careful not to modify the preprocessed version, `ghc.cabal`, as it will be overwritten next time you run `configure`.
To add a module to the `ghc` package:
- Add your module to the `exposed-modules` section of [compiler/ghc.cabal.in](/trac/ghc/browser/compiler/ghc.cabal.in)[](/trac/ghc/export/HEAD/ghc/compiler/ghc.cabal.in)
- Add your module to the `exposed-modules` section of [compiler/ghc.cabal.in](/ghc/ghc/tree/master/compiler/ghc.cabal.in)[](/trac/ghc/export/HEAD/ghc/compiler/ghc.cabal.in)
- `cd compiler; make stage2`
### Removing a source file from GHC
......@@ -92,7 +92,7 @@ To add a module to the `ghc` package:
To retire a GHC source file that is no longer needed:
- Remove the working copy of the file (git will notice it is gone), or use `git rm`.
- Remove the module from the list of modules in [compiler/ghc.cabal.in](/trac/ghc/browser/compiler/ghc.cabal.in)[](/trac/ghc/export/HEAD/ghc/compiler/ghc.cabal.in).
- Remove the module from the list of modules in [compiler/ghc.cabal.in](/ghc/ghc/tree/master/compiler/ghc.cabal.in)[](/trac/ghc/export/HEAD/ghc/compiler/ghc.cabal.in).
- To remove all mention of the file from derived dependency files, it is necessary to do something on the
order of
......@@ -124,9 +124,9 @@ To have the change propagated to the stage 2 compiler, either go and make stage
Adding a new package is quite straightforward:
- To arrange that the package is known to `./boot`, add an entry to the [packages](/trac/ghc/browser/packages)[](/trac/ghc/export/HEAD/ghc/packages) file.
- To arrange that the package is known to `./boot`, add an entry to the [packages](/ghc/ghc/tree/master/packages)[](/trac/ghc/export/HEAD/ghc/packages) file.
- run `perl boot` to generate the `ghc.mk` and `GNUmakefile` files in your package's build.
- Add an entry to the `PACKAGES` variable in [ghc.mk](/trac/ghc/browser/ghc.mk)[](/trac/ghc/export/HEAD/ghc/ghc.mk). The list in `PACKAGES` is kept in dependency order: each package must appear after the packages it depends on.
- Add an entry to the `PACKAGES` variable in [ghc.mk](/ghc/ghc/tree/master/ghc.mk)[](/trac/ghc/export/HEAD/ghc/ghc.mk). The list in `PACKAGES` is kept in dependency order: each package must appear after the packages it depends on.
That's it: doing a top-level `make` should now build your package and bring everything else up to date.
......@@ -192,7 +192,7 @@ $(eval $(call build-prog,utils/hpc,dist,1))
```
This is a call to the `build-prog` macro, whose definition can be found in [rules/build-prog.mk](/trac/ghc/browser/rules/build-prog.mk)[](/trac/ghc/export/HEAD/ghc/rules/build-prog.mk). This expands to the code for actually building the program, and it takes three arguments: the directory, the distdir, and the GHC stage to use for building (in this case we're using stage 1). The `build-prog` macro expects to find certain variables defined, namely *directory*_*distdir*`_PROG`, and *directory*_*distdir*`_MODULES`.
This is a call to the `build-prog` macro, whose definition can be found in [rules/build-prog.mk](/ghc/ghc/tree/master/rules/build-prog.mk)[](/trac/ghc/export/HEAD/ghc/rules/build-prog.mk). This expands to the code for actually building the program, and it takes three arguments: the directory, the distdir, and the GHC stage to use for building (in this case we're using stage 1). The `build-prog` macro expects to find certain variables defined, namely *directory*_*distdir*`_PROG`, and *directory*_*distdir*`_MODULES`.
Finally, for programs that we want to install, we need to include the `ghc.mk` file in a binary distribution:
......
......@@ -351,7 +351,7 @@ your OS.
The splitter is another evil Perl script
([driver/split/ghc-split.lprl](/trac/ghc/browser/ghc/driver/split/ghc-split.lprl)). Object splitting is what happens
([driver/split/ghc-split.lprl](/ghc/ghc/tree/master/ghc/driver/split/ghc-split.lprl)). Object splitting is what happens
when the `-split-objs` option is passed to GHC: the object file is
split into many smaller objects. This feature is used when building
libraries, so that a program statically linked against the library
......@@ -373,7 +373,7 @@ generator is described in detail in [Commentary/Compiler/Backends/NCG](commentar
To support GHCi, you need to port the dynamic linker
([rts/Linker.c](/trac/ghc/browser/ghc/rts/Linker.c)). The linker currently supports the
([rts/Linker.c](/ghc/ghc/tree/master/ghc/rts/Linker.c)). The linker currently supports the
ELF and PEi386 object file formats - if your platform uses one of
these then things will be significantly easier. The majority of Unix
platforms use the ELF format these days. Even so, there are some
......
......@@ -28,7 +28,7 @@ $ make test WAY=optasm TEST=tc053
The testsuite also has a concept called, *ways*. These refer to different settings in which a test case can be compiled and/or run. They correspond to things such as checking a test passes both when the native code generator is used and when the LLVM code generator is used.
The following ways are defined (see the file [testsuite/config/ghc](/trac/ghc/browser/ghc/testsuite/config/ghc)
The following ways are defined (see the file [testsuite/config/ghc](/ghc/ghc/tree/master/ghc/testsuite/config/ghc)
for the complete list):
```wiki
......@@ -55,7 +55,7 @@ certain ways are enabled automatically if the GHC build in the local
tree supports them. Ways that are enabled this way are `optasm`,
`optllvm`, `profasm`, `threaded1`, `threaded2`, `profthreaded`, `ghci`,
and whichever of `static`/`dyn` is not GHC's default mode.
See also: [testsuite/mk/test.mk](/trac/ghc/browser/ghc/testsuite/mk/test.mk).
See also: [testsuite/mk/test.mk](/ghc/ghc/tree/master/ghc/testsuite/mk/test.mk).
These values are supported for `VERBOSE=n`; the default is `VERBOSE=3`:
......
......@@ -18,7 +18,7 @@ The existing build system performs the following major steps:
- **configure**: take a bunch of `*.in` files {`config.mk.in`, `ghc.cabal.in`, `ghc-bin.cabal.in`, ...} and generate {`config.mk`, `ghc.cabal`, `ghc-bin.cabal`, ...}.
- **make**: do the rest of the build in three phases by invoking `ghc.mk` with the phase parameter set to one of {`0`, `1`, `final`}. All other `*.mk` files {`config.mk`, `tree.mk`, ...} are included in `ghc.mk`. The approximate build order is described in [ghc.mk](/trac/ghc/browser/ghc/ghc.mk)[](/trac/ghc/export/HEAD/ghc/ghc.mk).
- **make**: do the rest of the build in three phases by invoking `ghc.mk` with the phase parameter set to one of {`0`, `1`, `final`}. All other `*.mk` files {`config.mk`, `tree.mk`, ...} are included in `ghc.mk`. The approximate build order is described in [ghc.mk](/ghc/ghc/tree/master/ghc/ghc.mk)[](/trac/ghc/export/HEAD/ghc/ghc.mk).
The goal is to eventually replace all of the above with a single shake script that will be invoking `autoconf`, `configure`, etc., and taking care of all dependencies. Specific parts of the old build system that will be shake-ified are: `boot`, `ghc-cabal` and `*.mk`.
......
......@@ -7,7 +7,7 @@ Normally GHC will try to do a so-called registerised build, where it uses variou
To do an unregisterised build, use the `--enable-unregisterised` flag when configuring.
GHC will automatically do an unregisterised build on platforms that it knows don't currently have registerised support. See the variable `UnregisterisedDefault` in [configure.ac](/trac/ghc/browser/configure.ac)[](/trac/ghc/export/HEAD/ghc/configure.ac).
GHC will automatically do an unregisterised build on platforms that it knows don't currently have registerised support. See the variable `UnregisterisedDefault` in [configure.ac](/ghc/ghc/tree/master/configure.ac)[](/trac/ghc/export/HEAD/ghc/configure.ac).
The various part of GHC work with registerised and unregisterised as follows:
......
......@@ -221,7 +221,7 @@ To understand more about what you can put in `mk/build.mk`, read on.
The following are some common variables that you might want to set in
your `mk/build.mk`. For other variables that you can override,
take a look in [mk/config.mk.in](/trac/ghc/browser/ghc/mk/config.mk.in).
take a look in [mk/config.mk.in](/ghc/ghc/tree/master/ghc/mk/config.mk.in).
<table><tr><th>`SRC_HC_OPTS`</th>
<td>
......
......@@ -4,7 +4,7 @@
This wiki page is about the Call Arity analysis and transformation, which eta-expands definitions if we know that it is always being called with a certain number of arguments. This looks a the *uses* of a function, which is different from the the code in CoreArity, which looks at the *definition* of a function.
This pages does **not** document Call Arity as implemented; that documentation should be found and maintained with the code, at [source:compiler/simplCore/CallArity.hs](/trac/ghc/browser/compiler/simplCore/CallArity.hs)[](/trac/ghc/export/HEAD/ghc/compiler/simplCore/CallArity.hs).
This pages does **not** document Call Arity as implemented; that documentation should be found and maintained with the code, at [source:compiler/simplCore/CallArity.hs](/ghc/ghc/tree/master/compiler/simplCore/CallArity.hs)[](/trac/ghc/export/HEAD/ghc/compiler/simplCore/CallArity.hs).
This page used to discuss possible changes to the analysis, but these are implemented now (\[cb8a63c\]), so I removed the obsolete notes from here.
......
......@@ -235,7 +235,7 @@ To maintain compatibility, use [HsVersions.h](commentary/coding-style#) (see bel
### `HsVersions.h`
`HsVersions.h` is a CPP header file containing a number of macros that help smooth out the differences between compiler versions. It defines, for example, macros for library module names which have moved between versions. Take a look [compiler/HsVersions.h](/trac/ghc/browser/ghc/compiler/HsVersions.h).
`HsVersions.h` is a CPP header file containing a number of macros that help smooth out the differences between compiler versions. It defines, for example, macros for library module names which have moved between versions. Take a look [compiler/HsVersions.h](/ghc/ghc/tree/master/ghc/compiler/HsVersions.h).
```wiki
#include "HsVersions.h"
......
# GHC Commentary: The Compiler
The compiler itself is written entirely in Haskell, and lives in the many sub-directories of the [compiler](/trac/ghc/browser/ghc/compiler) directory.
The compiler itself is written entirely in Haskell, and lives in the many sub-directories of the [compiler](/ghc/ghc/tree/master/ghc/compiler) directory.
- [Compiler Module Dependencies](module-dependencies) (deals with the arcane mutual recursions among GHC's many data types)
- [Coding guidelines](commentary/coding-style)
......@@ -69,18 +69,18 @@ Here is a block diagram of its top-level structure:
The part called [HscMain](commentary/compiler/hsc-main) deals with compiling a single module. On top of this is built the **compilation manager** (in blue) that manages the compilation of multiple modules. It exports an interface called the **GHC API**. On top of this API are four small front ends:
- GHCi, the interactive environment, is implemented in [ghc/GHCi/UI.hs](/trac/ghc/browser/ghc/ghc/GHCi/UI.hs) and [compiler/main/InteractiveEval.hs](/trac/ghc/browser/ghc/compiler/main/InteractiveEval.hs). It sits squarely on top of the GHC API.
- GHCi, the interactive environment, is implemented in [ghc/GHCi/UI.hs](/ghc/ghc/tree/master/ghc/ghc/GHCi/UI.hs) and [compiler/main/InteractiveEval.hs](/trac/ghc/browser/ghc/compiler/main/InteractiveEval.hs). It sits squarely on top of the GHC API.
- `--make` is almost a trivial client of the GHC API, and is implemented in [compiler/main/GhcMake.hs](/trac/ghc/browser/ghc/compiler/main/GhcMake.hs).
- `--make` is almost a trivial client of the GHC API, and is implemented in [compiler/main/GhcMake.hs](/ghc/ghc/tree/master/ghc/compiler/main/GhcMake.hs).
- `-M`, the Makefile dependency generator, is also a client of the GHC API and is implemented in [compiler/main/DriverMkDepend.hs](/trac/ghc/browser/ghc/compiler/main/DriverMkDepend.hs).
- `-M`, the Makefile dependency generator, is also a client of the GHC API and is implemented in [compiler/main/DriverMkDepend.hs](/ghc/ghc/tree/master/ghc/compiler/main/DriverMkDepend.hs).
- The "one-shot" mode, where GHC compiles each file on the command line separately (eg. `ghc -c Foo.hs`). This mode bypasses the GHC API, and is implemented
directly on top of [HscMain](commentary/compiler/hsc-main), since it compiles only one file at a time. In fact, this is all that
GHC consisted of prior to version 5.00 when GHCi and `--make` were introduced.
GHC is packaged as a single binary in which all of these front-ends are present, selected by the command-line flags indicated above. There is a single command-line interface implemented in [ghc/Main.hs](/trac/ghc/browser/ghc/ghc/Main.hs).
GHC is packaged as a single binary in which all of these front-ends are present, selected by the command-line flags indicated above. There is a single command-line interface implemented in [ghc/Main.hs](/ghc/ghc/tree/master/ghc/ghc/Main.hs).
In addition, GHC is compiled, without its front ends, as a *library* which can be imported by any Haskell program; see [the GHC API](commentary/compiler/api).
......@@ -52,7 +52,7 @@ The `hscTarget` field of `DynFlags` tells the compiler what kind of output to ge
The targets specify the source files or modules at the top of the dependency tree. For a Haskell program there is often just a single target `Main.hs`, but for a library the targets would consist of every visible module in the library.
The `Target` type is defined in [compiler/main/HscTypes.hs](/trac/ghc/browser/ghc/compiler/main/HscTypes.hs). Note that a `Target` includes not just the file or module name, but also optionally the complete source text of the module as a `StringBuffer`: this is to support an interactive development environment where the source file is being edited, and the in-memory copy of the source file is to be used in preference to the version on disk.
The `Target` type is defined in [compiler/main/HscTypes.hs](/ghc/ghc/tree/master/ghc/compiler/main/HscTypes.hs). Note that a `Target` includes not just the file or module name, but also optionally the complete source text of the module as a `StringBuffer`: this is to support an interactive development environment where the source file is being edited, and the in-memory copy of the source file is to be used in preference to the version on disk.
## Dependency Analysis
......@@ -65,7 +65,7 @@ The `downsweep` function takes the targets and returns a list of `ModSummary` co
## The ModSummary type
A `ModSummary` (defined in [compiler/main/HscTypes.hs](/trac/ghc/browser/ghc/compiler/main/HscTypes.hs)) contains various information about a module:
A `ModSummary` (defined in [compiler/main/HscTypes.hs](/ghc/ghc/tree/master/ghc/compiler/main/HscTypes.hs)) contains various information about a module:
- Its `Module`, which includes the package that it belongs to
- Its `ModLocation`, which lists the pathnames of all the files associated with the module
......@@ -74,10 +74,10 @@ A `ModSummary` (defined in [compiler/main/HscTypes.hs](/trac/ghc/browser/ghc/com
- ... some other things
We collect `ModSumary` information for all the modules we are interested in during the *downsweep*, below. Extracting the information about the module name and the imports from a source file is the job of [compiler/main/HeaderInfo.hs](/trac/ghc/browser/ghc/compiler/main/HeaderInfo.hs) which partially parses the source file.
We collect `ModSumary` information for all the modules we are interested in during the *downsweep*, below. Extracting the information about the module name and the imports from a source file is the job of [compiler/main/HeaderInfo.hs](/ghc/ghc/tree/master/ghc/compiler/main/HeaderInfo.hs) which partially parses the source file.
Converting a given module name into a `ModSummary` is done by `summariseModule` in [compiler/main/GHC.hs](/trac/ghc/browser/ghc/compiler/main/GHC.hs). Similarly, if we have a filename rather than a module name, we generate a `ModSummary` using `summariseFile`.
Converting a given module name into a `ModSummary` is done by `summariseModule` in [compiler/main/GHC.hs](/ghc/ghc/tree/master/ghc/compiler/main/GHC.hs). Similarly, if we have a filename rather than a module name, we generate a `ModSummary` using `summariseFile`.
## Loading (compiling) the Modules
......
......@@ -19,37 +19,37 @@ NOTE! The native code generator was largely rewritten as part of the C-- backend
### Files, Parts
After GHC has produced [Cmm](commentary/compiler/cmm-type) (use -ddump-cmm or -ddump-opt-cmm to view), the Native Code Generator (NCG) transforms Cmm into architecture-specific assembly code. The NCG is located in [compiler/nativeGen](/trac/ghc/browser/ghc/compiler/nativeGen) and is separated into eight modules:
After GHC has produced [Cmm](commentary/compiler/cmm-type) (use -ddump-cmm or -ddump-opt-cmm to view), the Native Code Generator (NCG) transforms Cmm into architecture-specific assembly code. The NCG is located in [compiler/nativeGen](/ghc/ghc/tree/master/ghc/compiler/nativeGen) and is separated into eight modules:
- [compiler/nativeGen/AsmCodeGen.hs](/trac/ghc/browser/ghc/compiler/nativeGen/AsmCodeGen.hs)
- [compiler/nativeGen/AsmCodeGen.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/AsmCodeGen.hs)
top-level module for the NCG, imported by [compiler/main/CodeOutput.hs](/trac/ghc/browser/ghc/compiler/main/CodeOutput.hs); also defines the Monad for optimising generic Cmm code, `CmmOptM`
- [compiler/nativeGen/MachCodeGen.hs](/trac/ghc/browser/ghc/compiler/nativeGen/MachCodeGen.hs)
top-level module for the NCG, imported by [compiler/main/CodeOutput.hs](/ghc/ghc/tree/master/ghc/compiler/main/CodeOutput.hs); also defines the Monad for optimising generic Cmm code, `CmmOptM`
- [compiler/nativeGen/MachCodeGen.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/MachCodeGen.hs)
generates architecture-specific instructions (a Haskell-representation of assembler) from Cmm code
- [compiler/nativeGen/MachInstrs.hs](/trac/ghc/browser/ghc/compiler/nativeGen/MachInstrs.hs)
- [compiler/nativeGen/MachInstrs.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/MachInstrs.hs)
contains data definitions and some functions (comparison, size, simple conversions) for machine instructions, mostly carried out through the `Instr` data type, defined here
- [compiler/nativeGen/NCGMonad.hs](/trac/ghc/browser/ghc/compiler/nativeGen/NCGMonad.hs)
- [compiler/nativeGen/NCGMonad.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/NCGMonad.hs)
defines the the main monad in the NCG: the Native code Machine instruction Monad, `NatM`, and related functions. *Note: the NCG switches between two monads at times, especially in `AsmCodeGen`: `NatM` and the `UniqSM` Monad used throughout the compiler.*
- [compiler/nativeGen/PIC.hs](/trac/ghc/browser/ghc/compiler/nativeGen/PIC.hs)
- [compiler/nativeGen/PIC.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/PIC.hs)
handles generation of position independent code and issues related to dynamic linking in the NCG; related to many other modules outside the NCG that handle symbol import, export and references, including `CLabel`, `Cmm`, `codeGen` and the RTS, and the Mangler
- [compiler/nativeGen/PprMach.hs](/trac/ghc/browser/ghc/compiler/nativeGen/PprMach.hs)
- [compiler/nativeGen/PprMach.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/PprMach.hs)
Pretty prints machine instructions (`Instr`) to assembler code (currently readable by GNU's `as`), with some small modifications, especially for comparing and adding floating point numbers on x86 architectures
- [compiler/nativeGen/RegAllocInfo.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegAllocInfo.hs)
- [compiler/nativeGen/RegAllocInfo.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegAllocInfo.hs)
defines the main register information function, `regUsage`, which takes a set of real and virtual registers and returns the actual registers used by a particular `Instr`; register allocation is in AT&T syntax order (source, destination), in an internal function, `usage`; defines the `RegUsage` data type
- [compiler/nativeGen/RegisterAlloc.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegisterAlloc.hs)
- [compiler/nativeGen/RegisterAlloc.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegisterAlloc.hs)
one of the most complicated modules in the NCG, `RegisterAlloc` manages the allocation of registers for each *basic block* of Haskell-abstracted assembler code: management involves *liveness* analysis, allocation or deletion of temporary registers, *spilling* temporary values to the *spill stack* (memory) and many optimisations. *See [The Cmm language](commentary/compiler/cmm-type) for the definition of a *basic block* (in Haskell, *`type CmmBasicBlock = GenBasicBlock CmmStmt`*).*
and one header file:
- [compiler/nativeGen/NCG.h](/trac/ghc/browser/ghc/compiler/nativeGen/NCG.h)
- [compiler/nativeGen/NCG.h](/ghc/ghc/tree/master/ghc/compiler/nativeGen/NCG.h)
defines macros used to separate architecture-specific code in the Haskell NCG files; since GHC currently only generates machine code for the architecture on which it was compiled (GHC is not currently a cross-compiler), the Haskell NCG files become considerably smaller after preprocessing; ideally all architecture-specific code would reside in separate files and GHC would have them available to support cross-compiler capabilities.
......
......@@ -164,4 +164,4 @@ These are some ideas for improving the current allocator, most potentially usefu
For the architectures currently supported, x86, x86_64 and ppc, the native code generator currently emits code using only two register classes `RcInteger` and `RcDouble`. As these classes are disjoint (ie, none of the regs from one class alias with with regs from another), checking whether a node of a certain class is trivially colorable reduces to counting up the number of neighbours of that class.
> >
> > If the NCG starts to use aliasing register classes eg: both 32bit `RcFloat`s and 64bit `RcDouble`s on sparc; combinations of 8, 16, and 32 bit integers on x86 / x86_x6 or usage of sse / altivec regs in different modes, then this can be supported via the method described in \[Smith et al\]. The allocator was designed with this in mind - ie, by passing a function to test if a node is trivially colorable as a parameter to the coloring function - and there is already a description of the register set for x86 in [compiler/nativeGen/RegArchX86.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegArchX86.hs), but the native code generator doesn't currently emit code to test it against.
> > If the NCG starts to use aliasing register classes eg: both 32bit `RcFloat`s and 64bit `RcDouble`s on sparc; combinations of 8, 16, and 32 bit integers on x86 / x86_x6 or usage of sse / altivec regs in different modes, then this can be supported via the method described in \[Smith et al\]. The allocator was designed with this in mind - ie, by passing a function to test if a node is trivially colorable as a parameter to the coloring function - and there is already a description of the register set for x86 in [compiler/nativeGen/RegArchX86.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegArchX86.hs), but the native code generator doesn't currently emit code to test it against.
......@@ -5,66 +5,66 @@ The register allocator code is split into two main sections, the register alloca
### The register allocator
- [compiler/nativeGen/RegLiveness.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegLiveness.hs)
- [compiler/nativeGen/RegLiveness.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegLiveness.hs)
Defines `LiveInstr` and `LiveCmmTop` which carry native machine instructions annotated with register liveness information. It also provides functions to annotate native code (`NatCmmTop`) with this liveness information, and to slurp out sets of register conflicts for feeding into the coloring allocator.
- [compiler/nativeGen/RegAllocColor.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegAllocColor.hs)
- [compiler/nativeGen/RegAllocColor.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegAllocColor.hs)
Defines `regAlloc`, the main driver function for the graph coloring allocator. The driver accepts `LiveCmmTop`s which use virtual regs, and produces`NatCmmTops` which use real machine regs. This module also provides functions to help build and deep seq the register conflict graph.
- [compiler/nativeGen/RegAllocLinear.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegAllocLinear.hs)
- [compiler/nativeGen/RegAllocLinear.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegAllocLinear.hs)
Defines the linear scan allocator. Its interface is identical to the coloring allocator.
- [compiler/nativeGen/RegAllocInfo.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegAllocInfo.hs)
- [compiler/nativeGen/RegAllocInfo.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegAllocInfo.hs)
Defines the register information function, `regUsage`, which takes a set of real and virtual registers and returns the actual registers used by a particular `Instr`; register allocation is in AT&T syntax order (source, destination), in an internal function, `usage`; defines the `RegUsage` data type
- [compiler/nativeGen/RegSpillCost.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegSpillCost.hs)
- [compiler/nativeGen/RegSpillCost.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegSpillCost.hs)
Defines `chooseSpill` which is responsible for selecting a virtual reg to spill to the stack when not enough real regs are available.
- [compiler/nativeGen/RegSpill.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegSpill.hs)
- [compiler/nativeGen/RegSpill.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegSpill.hs)
Defines `regSpill` which takes `LiveCmmTop`s and inserts spill/reload instructions virtual regs that wouldn't fit in real regs. `regSpill`'s strategy is to simply inserts spill/reloads for every use/def of a particular virtual reg. This inefficient code is cleaned up by the spill cleaner after allocation.
- [compiler/nativeGen/RegSpillClean.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegSpillClean.hs)
- [compiler/nativeGen/RegSpillClean.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegSpillClean.hs)
The spill cleaner is run after real regs have been allocated. It erases spill/reload instructions inserted by `regSpill` that weren't strictly nessesary.
- [compiler/nativeGen/RegAllocStats.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegAllocStats.hs)
- [compiler/nativeGen/RegAllocStats.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegAllocStats.hs)
Defines data types and pretty printers used for collecting statistics and debugging info from the coloring allocator.
### Graph coloring
- [compiler/utils/GraphBase.hs](/trac/ghc/browser/ghc/compiler/utils/GraphBase.hs)
- [compiler/utils/GraphBase.hs](/ghc/ghc/tree/master/ghc/compiler/utils/GraphBase.hs)
Defines the basic `Graph`, `Node` and `Triv` types used by the coloring algorithm.
- [compiler/utils/GraphColor.hs](/trac/ghc/browser/ghc/compiler/utils/GraphColor.hs)
- [compiler/utils/GraphColor.hs](/ghc/ghc/tree/master/ghc/compiler/utils/GraphColor.hs)
Defines the function `colorGraph` which is responsible for assigning colors (real regs) to nodes (virtual regs) in the register conflict graph.
- [compiler/utils/GraphOps.hs](/trac/ghc/browser/ghc/compiler/utils/GraphOps.hs)
- [compiler/utils/GraphOps.hs](/ghc/ghc/tree/master/ghc/compiler/utils/GraphOps.hs)
Defines functions to perform basic operations on the graphs such as adding, deleting, and coalescing nodes.
- [compiler/utils/GraphPps.hs](/trac/ghc/browser/ghc/compiler/utils/GraphPps.hs)
- [compiler/utils/GraphPps.hs](/ghc/ghc/tree/master/ghc/compiler/utils/GraphPps.hs)
Defines functions for pretty print graphs in human readable-ish and graphviz format.
### Miscellanea
- [compiler/nativeGen/RegCoalesce.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegCoalesce.hs)
- [compiler/nativeGen/RegCoalesce.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegCoalesce.hs)
Defines a function `regCoalesce` that does aggressive coalescing directly on `LiveCmmTops`, without using the graph. This isn't used at the moment but has been left in incase we want to rejig the allocator when the new CPS converter comes online.
- [compiler/nativeGen/RegArchBase.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegArchBase.hs)
- [compiler/nativeGen/RegArchBase.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegArchBase.hs)
Defines utils for calculating whether a register in the conflict graph is trivially colorable, in a generic way which handles aliasing between register classes. This module is not used directly by GHC.
- [compiler/nativeGen/RegArchX86.hs](/trac/ghc/browser/ghc/compiler/nativeGen/RegArchX86.hs)
- [compiler/nativeGen/RegArchX86.hs](/ghc/ghc/tree/master/ghc/compiler/nativeGen/RegArchX86.hs)
Contains a description of the aliasing constraints between the register sets on x86. This module is not used directly by GHC.
# GHC Commentary: The C code generator
Source: [compiler/cmm/PprC.hs](/trac/ghc/browser/ghc/compiler/cmm/PprC.hs)
Source: [compiler/cmm/PprC.hs](/ghc/ghc/tree/master/ghc/compiler/cmm/PprC.hs)
This phase takes [Cmm](commentary/compiler/cmm-type) and generates plain C code. The C code generator is very simple these days, in fact it can almost be considered pretty-printing. It is only used for unregisterised compilers.
......@@ -69,7 +69,7 @@ declarations don't overlap. So we either have to scan the whole code to figure
will do here.
- all RTS symbols already have declarations (mostly with the correct
type) in [includes/StgMiscClosures.h](/trac/ghc/browser/ghc/includes/StgMiscClosures.h), so no declarations are generated.
type) in [includes/StgMiscClosures.h](/ghc/ghc/tree/master/ghc/includes/StgMiscClosures.h), so no declarations are generated.
- certain labels are known to have been defined earlier in the same file,
so a declaration can be omitted (e.g. SRT labels)
......@@ -89,6 +89,6 @@ we need to emit special code to reference these labels).
For all other labels referenced by RTS .cmm code, we assume they are
RTS labels, and hence already declared in [includes/StgMiscClosures.h](/trac/ghc/browser/ghc/includes/StgMiscClosures.h). This is
RTS labels, and hence already declared in [includes/StgMiscClosures.h](/ghc/ghc/tree/master/ghc/includes/StgMiscClosures.h). This is
the only choice here: since we don't know the type of the label (info,
entry etc.), we can't generate a correct declaration.
......@@ -6,7 +6,7 @@ This page gives a hopefully comprehensive view of how `Bool` type is wired-in in
## Constants for Bool type and data constructors
All data constructors, type constructors and so on have their unique identifier which is needed during the compilation process. For the wired-in types these unique values are defined in the [compiler/prelude/PrelNames.hs](/trac/ghc/browser/ghc/compiler/prelude/PrelNames.hs). In case of `Bool` the relevant definitions look like this:
All data constructors, type constructors and so on have their unique identifier which is needed during the compilation process. For the wired-in types these unique values are defined in the [compiler/prelude/PrelNames.hs](/ghc/ghc/tree/master/ghc/compiler/prelude/PrelNames.hs). In case of `Bool` the relevant definitions look like this:
```wiki
boolTyConKey, falseDataConKey, trueDataConKey :: Unique
......@@ -18,7 +18,7 @@ trueDataConKey = mkPreludeDataConUnique 15 -- line 1451
### A side note on generating Unique values
The `mkPreludeTyConUnique` and `mkPreludeDataConUnique` take care of generating a unique `Unique` value. They are defined in [compiler/basicTypes/Unique.hs](/trac/ghc/browser/ghc/compiler/basicTypes/Unique.hs):
The `mkPreludeTyConUnique` and `mkPreludeDataConUnique` take care of generating a unique `Unique` value. They are defined in [compiler/basicTypes/Unique.hs](/ghc/ghc/tree/master/ghc/compiler/basicTypes/Unique.hs):
```wiki
data Unique = MkUnique FastInt
......@@ -31,12 +31,12 @@ mkPreludeDataConUnique i = mkUnique '6' (2*i)
```
You will find definition of `mkUnique :: Char -> Int -> Unique` at line 135 in [compiler/basicTypes/Unique.hs](/trac/ghc/browser/ghc/compiler/basicTypes/Unique.hs).
You will find definition of `mkUnique :: Char -> Int -> Unique` at line 135 in [compiler/basicTypes/Unique.hs](/ghc/ghc/tree/master/ghc/compiler/basicTypes/Unique.hs).
## Defining wired-in information about Bool
All the wired-in information that compiler needs to know about `Bool` is defined in [compiler/prelude/TysWiredIn.hs](/trac/ghc/browser/ghc/compiler/prelude/TysWiredIn.hs). This file exports following functions related to `Bool`:
All the wired-in information that compiler needs to know about `Bool` is defined in [compiler/prelude/TysWiredIn.hs](/ghc/ghc/tree/master/ghc/compiler/prelude/TysWiredIn.hs). This file exports following functions related to `Bool`:
```wiki
boolTy, boolTyCon, boolTyCon_RDR, boolTyConName,
......@@ -62,13 +62,13 @@ falseDataConName = mkWiredInDataConName UserSyntax gHC_TYPES (fsLit "False") fa
trueDataConName = mkWiredInDataConName UserSyntax gHC_TYPES (fsLit "True") trueDataConKey trueDataCon
```
`boolTyConKey`, `falseDataConKey` and `trueDataConKey` are `Unique` values defined earlier. `boolTyCon`, `falseDataCon` and `trueDataCon` are yet undefined. Type of syntax is defined in [compiler/basicTypes/Name.hs](/trac/ghc/browser/ghc/compiler/basicTypes/Name.hs), line 129:
`boolTyConKey`, `falseDataConKey` and `trueDataConKey` are `Unique` values defined earlier. `boolTyCon`, `falseDataCon` and `trueDataCon` are yet undefined. Type of syntax is defined in [compiler/basicTypes/Name.hs](/ghc/ghc/tree/master/ghc/compiler/basicTypes/Name.hs), line 129:
```wiki
data BuiltInSyntax = BuiltInSyntax | UserSyntax
```
`BuiltInSyntax` is used for things like (:), \[\] and tuples. All other things are `UserSyntax`. `gHC_TYPES` is a module `GHC.Types` to which these type and data constructors get assigned. It is defined in [compiler/prelude/PrelNames.hs](/trac/ghc/browser/ghc/compiler/prelude/PrelNames.hs):
`BuiltInSyntax` is used for things like (:), \[\] and tuples. All other things are `UserSyntax`. `gHC_TYPES` is a module `GHC.Types` to which these type and data constructors get assigned. It is defined in [compiler/prelude/PrelNames.hs](/ghc/ghc/tree/master/ghc/compiler/prelude/PrelNames.hs):
```wiki
gHC_TYPES = mkPrimModule (fsLit "GHC.Types") -- line 359
......@@ -77,7 +77,7 @@ mkPrimModule :: FastString -> Module -- line 435
mkPrimModule m = mkModule primPackageId (mkModuleNameFS m)
```
`FastString` is a string type based on `ByteStrings` and the `fsLit` function converts a standard Haskell `Strings` to `FastString`. See [compiler/utils/FastString.hs](/trac/ghc/browser/ghc/compiler/utils/FastString.hs) for more details.
`FastString` is a string type based on `ByteStrings` and the `fsLit` function converts a standard Haskell `Strings` to `FastString`. See [compiler/utils/FastString.hs](/ghc/ghc/tree/master/ghc/compiler/utils/FastString.hs) for more details.
### A side note on creating wired-in Names
......@@ -100,7 +100,7 @@ data NameSort
```
The `mkWiredInTyConName` and `mkWiredInDataConName` are functions that create `Name`s for wired in types and data constructors. They are defined in [compiler/prelude/TysWiredIn.hs](/trac/ghc/browser/ghc/compiler/prelude/TysWiredIn.hs), lines 163-173:
The `mkWiredInTyConName` and `mkWiredInDataConName` are functions that create `Name`s for wired in types and data constructors. They are defined in [compiler/prelude/TysWiredIn.hs](/ghc/ghc/tree/master/ghc/compiler/prelude/TysWiredIn.hs), lines 163-173:
```wiki
mkWiredInTyConName :: BuiltInSyntax -> Module -> FastString -> Unique -> TyCon -> Name
......@@ -117,7 +117,7 @@ mkWiredInDataConName built_in modu fs unique datacon
```
The `mkWiredInName` is defined in [compiler/basicTypes/Name.hs](/trac/ghc/browser/ghc/compiler/basicTypes/Name.hs) (lines 279-283), and it just assigns values to fields of `Name`:
The `mkWiredInName` is defined in [compiler/basicTypes/Name.hs](/ghc/ghc/tree/master/ghc/compiler/basicTypes/Name.hs) (lines 279-283), and it just assigns values to fields of `Name`:
```wiki
mkWiredInName :: Module -> OccName -> Unique -> TyThing -> BuiltInSyntax -> Name
......@@ -130,7 +130,7 @@ mkWiredInName mod occ uniq thing built_in
## RdrNames for Bool
Having defined `Name`s for `Bool`, the [RdrName](commentary/compiler/rdr-name-type)s can be defined ([compiler/prelude/TysWiredIn.hs](/trac/ghc/browser/ghc/compiler/prelude/TysWiredIn.hs), lines 221-225):
Having defined `Name`s for `Bool`, the [RdrName](commentary/compiler/rdr-name-type)s can be defined ([compiler/prelude/TysWiredIn.hs](/ghc/ghc/tree/master/ghc/compiler/prelude/TysWiredIn.hs), lines 221-225):
```wiki
boolTyCon_RDR, false_RDR, true_RDR :: RdrName
......@@ -170,14 +170,14 @@ Note that `boolTyCon` is on the list of wired in type constructors created by `w
### A side note on functions generating type and data constructors
[compiler/types/TypeRep.hs](/trac/ghc/browser/ghc/compiler/types/TypeRep.hs), lines 281-282:
[compiler/types/TypeRep.hs](/ghc/ghc/tree/master/ghc/compiler/types/TypeRep.hs), lines 281-282:
```wiki
mkTyConTy :: TyCon -> Type
mkTyConTy tycon = TyConApp tycon []
```
[compiler/prelude/TysWiredIn.hs](/trac/ghc/browser/ghc/compiler/prelude/TysWiredIn.hs), 247-257:
[compiler/prelude/TysWiredIn.hs](/ghc/ghc/tree/master/ghc/compiler/prelude/TysWiredIn.hs), 247-257:
```wiki
pcTyCon :: Bool -> RecFlag -> Name -> Maybe CType -> [TyVar] -> [DataCon] -> TyCon
......@@ -239,7 +239,7 @@ falseDataConId = dataConWorkId falseDataCon
trueDataConId = dataConWorkId trueDataCon
```
`falseDataConId` and `trueDataConId` just extract `Id` from previously defined data constructors. These definitions are from [compiler/basicTypes/DataCon.hs](/trac/ghc/browser/ghc/compiler/basicTypes/DataCon.hs):
`falseDataConId` and `trueDataConId` just extract `Id` from previously defined data constructors. These definitions are from [compiler/basicTypes/DataCon.hs](/ghc/ghc/tree/master/ghc/compiler/basicTypes/DataCon.hs):
```wiki
data DataCon -- line 253
......
This diff is collapsed.
......@@ -7,13 +7,13 @@ The root page for codegen stuff is [Commentary/Compiler/CodeGen](commentary/comp
The goal of the code generator is to convert program from [STG](commentary/compiler/generated-code) representation to [Cmm](commentary/compiler/cmm-type) representation. STG is a functional language with explicit stack. Cmm is a low-level imperative language - something between C and assembly - that is suitable for machine code generation. Note that terminology might be a bit confusing here: the term "code generator" can refer both to STG-\>Cmm pass and the whole STG-\>Cmm-\>assembly pass. The Cmm-\>assembly conversion is performed by one the backends, eg. NCG (Native Code Generator or LLVM.
The top-most entry point to the codegen is located in [compiler/main/HscMain.hs](/trac/ghc/browser/ghc/compiler/main/HscMain.hs) in the `doCodeGen` function. Code generation is done in two stages:
The top-most entry point to the codegen is located in [compiler/main/HscMain.hs](/ghc/ghc/tree/master/ghc/compiler/main/HscMain.hs) in the `doCodeGen` function. Code generation is done in two stages:
1. Convert STG to Cmm with implicit stack, and native Cmm calls. This whole stage lives in [compiler/codeGen](/trac/ghc/browser/ghc/compiler/codeGen) directory with the entry point being `codeGen` function in [compiler/codeGen/StgCmm.hs](/trac/ghc/browser/ghc/compiler/codeGen/StgCmm.hs) module.
1. Optimise the Cmm, and CPS-convert it to have an explicit stack, and no native calls. This lives in [compiler/cmm](/trac/ghc/browser/ghc/compiler/cmm) directory with the `cmmPipeline` function from [compiler/cmm/CmmPipeline.hs](/trac/ghc/browser/ghc/compiler/cmm/CmmPipeline.hs) module being the entry point.
1. Convert STG to Cmm with implicit stack, and native Cmm calls. This whole stage lives in [compiler/codeGen](/ghc/ghc/tree/master/ghc/compiler/codeGen) directory with the entry point being `codeGen` function in [compiler/codeGen/StgCmm.hs](/trac/ghc/browser/ghc/compiler/codeGen/StgCmm.hs) module.
1. Optimise the Cmm, and CPS-convert it to have an explicit stack, and no native calls. This lives in [compiler/cmm](/ghc/ghc/tree/master/ghc/compiler/cmm) directory with the `cmmPipeline` function from [compiler/cmm/CmmPipeline.hs](/trac/ghc/browser/ghc/compiler/cmm/CmmPipeline.hs) module being the entry point.
The CPS-converted Cmm is fed to one of the backends. This is done by `codeOutput` function ([compiler/main/CodeOutput.hs](/trac/ghc/browser/ghc/compiler/main/CodeOutput.hs)) called from `hscGenHardCode` after returning from `doCodeGen`.
The CPS-converted Cmm is fed to one of the backends. This is done by `codeOutput` function ([compiler/main/CodeOutput.hs](/ghc/ghc/tree/master/ghc/compiler/main/CodeOutput.hs)) called from `hscGenHardCode` after returning from `doCodeGen`.
## First stage: STG to Cmm conversion
......@@ -29,7 +29,7 @@ The CPS-converted Cmm is fed to one of the backends. This is done by `codeOutput
## Second stage: the Cmm pipeline
The core of the Cmm pipeline is implemented by the `cpsTop` function in [compiler/cmm/CmmPipeline.hs](/trac/ghc/browser/ghc/compiler/cmm/CmmPipeline.hs) module. Below is a high-level overview of the pipeline. See source code comments in respective modules for a more in-depth explanation of each pass.
The core of the Cmm pipeline is implemented by the `cpsTop` function in [compiler/cmm/CmmPipeline.hs](/ghc/ghc/tree/master/ghc/compiler/cmm/CmmPipeline.hs) module. Below is a high-level overview of the pipeline. See source code comments in respective modules for a more in-depth explanation of each pass.
- **Control Flow Optimisations**, implemented in `CmmContFlowOpt`, simplifies the control flow graph by: