Commit e483f083 authored by Tobias Dammers's avatar Tobias Dammers 🦈

Fix links to GHC source code

parent 287304d0
......@@ -51,7 +51,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.
......@@ -138,7 +138,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:
......
......@@ -160,5 +160,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
......
......@@ -84,12 +84,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
......@@ -98,7 +98,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
......@@ -133,9 +133,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.
......@@ -201,7 +201,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:
......
......@@ -363,7 +363,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
......@@ -385,7 +385,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:
......
......@@ -229,7 +229,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><tt>SRC_HC_OPTS</tt></th>
......
......@@ -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)
......@@ -83,14 +83,14 @@ The part called [HscMain](commentary/compiler/hsc-main) deals with compiling a s
- `--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).
- `-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.
......
# 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.
......@@ -81,7 +81,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)
......@@ -101,6 +101,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:
......
......@@ -4,7 +4,7 @@
GHC's many flavours of command line flags make the code interpreting them rather involved. The following provides a brief overview of the processing of these options. Since the addition of the interactive front-end to GHC, there are two kinds of flags: static and dynamic. Static flags can only be set once on the command line. They remain the same throughout the whole GHC session (so for example you cannot change them within GHCi using `:set` or with `OPTIONS_GHC` pragma in the source code). Dynamic flags are the opposite: they can be changed in GHCi sessions using `:set` command or `OPTIONS_GHC` pragma in the source code. There are few static flags and it is likely that in the future there will be even less. Thus, you won't see many static flag references in the source code, but you will see a lot of functions that use dynamic flags.
Command line flags are described by Flag data type defined in [compiler/main/CmdLineParser.hs](/trac/ghc/browser/ghc/compiler/main/CmdLineParser.hs):
Command line flags are described by Flag data type defined in [compiler/main/CmdLineParser.hs](/ghc/ghc/tree/master/ghc/compiler/main/CmdLineParser.hs):
```wiki
data Flag m = Flag
......@@ -20,18 +20,18 @@ This file contains functions that actually parse the command line parameters.
## Static flags
Static flags are managed by functions in [compiler/main/StaticFlags.hs](/trac/ghc/browser/ghc/compiler/main/StaticFlags.hs).
Static flags are managed by functions in [compiler/main/StaticFlags.hs](/ghc/ghc/tree/master/ghc/compiler/main/StaticFlags.hs).
Function `parseStaticFlags ::` is an entry point for parsing static flags. It is called by the `main :: IO ()` function of GHC in [ghc/Main.hs](/trac/ghc/browser/ghc/ghc/Main.hs). Two global IORefs are used to parse static flags: `v_opt_C_ready` and `v_opt_C`. These are defined using `GLOBAL_VAR` macro from [compiler/HsVersions.h](/trac/ghc/browser/ghc/compiler/HsVersions.h). First IORef is a flag that checks whether the static flags are parsed at the right time. Initialized to `False`, it is set to `True` after the parsing is done. `v_opt_C` is a `[String]` used to store parsed flags (see `addOpt` and `removeOpt` functions).
Function `parseStaticFlags ::` is an entry point for parsing static flags. It is called by the `main :: IO ()` function of GHC in [ghc/Main.hs](/ghc/ghc/tree/master/ghc/ghc/Main.hs). Two global IORefs are used to parse static flags: `v_opt_C_ready` and `v_opt_C`. These are defined using `GLOBAL_VAR` macro from [compiler/HsVersions.h](/trac/ghc/browser/ghc/compiler/HsVersions.h). First IORef is a flag that checks whether the static flags are parsed at the right time. Initialized to `False`, it is set to `True` after the parsing is done. `v_opt_C` is a `[String]` used to store parsed flags (see `addOpt` and `removeOpt` functions).
In [compiler/main/StaticFlags.hs](/trac/ghc/browser/ghc/compiler/main/StaticFlags.hs), `flagsStatic :: [Flag IO]` defines a list of static flags and what actions should be taken when these flags are encountered (see `Flag` data type above). It also contains some helper functions to check whether particular flags have been set. Functions `staticFlags :: [String]` and `packed_staticFlags :: [FastString]` return a list of parsed command line static flags, provided that parsing has been done (checking the value of `v_opt_C_ready`).
In [compiler/main/StaticFlags.hs](/ghc/ghc/tree/master/ghc/compiler/main/StaticFlags.hs), `flagsStatic :: [Flag IO]` defines a list of static flags and what actions should be taken when these flags are encountered (see `Flag` data type above). It also contains some helper functions to check whether particular flags have been set. Functions `staticFlags :: [String]` and `packed_staticFlags :: [FastString]` return a list of parsed command line static flags, provided that parsing has been done (checking the value of `v_opt_C_ready`).
## Dynamic flags
They are managed by functions in [compiler/main/DynFlags.hs](/trac/ghc/browser/ghc/compiler/main/DynFlags.hs) file. Looking from the top you will find data types used to described enabled dynamic flags: `DumpFlag`, `GeneralFlag`, `WarningFlag`, `Language`, `SafeHaskellMode`, `ExtensionFlag` and finally `DynFlags`. Function `defaultDynFlags :: Settings -> DynFlags` initializes some of the flags to default values. Available dynamic flags and their respective actions are defined by `dynamic_flags :: [Flag (CmdLineP DynFlags)]`. Also, `fWarningFlags :: [FlagSpec WarningFlag]`, `fFlags :: [FlagSpec GeneralFlag]`, `xFlags :: [FlagSpec ExtensionFlag]` and a few more smaller functions define even more flags needed for example for language extensions, warnings and other things. These flags are descibred by the data type `FlagSpec f`:
They are managed by functions in [compiler/main/DynFlags.hs](/ghc/ghc/tree/master/ghc/compiler/main/DynFlags.hs) file. Looking from the top you will find data types used to described enabled dynamic flags: `DumpFlag`, `GeneralFlag`, `WarningFlag`, `Language`, `SafeHaskellMode`, `ExtensionFlag` and finally `DynFlags`. Function `defaultDynFlags :: Settings -> DynFlags` initializes some of the flags to default values. Available dynamic flags and their respective actions are defined by `dynamic_flags :: [Flag (CmdLineP DynFlags)]`. Also, `fWarningFlags :: [FlagSpec WarningFlag]`, `fFlags :: [FlagSpec GeneralFlag]`, `xFlags :: [FlagSpec ExtensionFlag]` and a few more smaller functions define even more flags needed for example for language extensions, warnings and other things. These flags are descibred by the data type `FlagSpec f`:
```wiki
type FlagSpec flag
......
......@@ -8,24 +8,24 @@ Video: [GHC Core language](http://www.youtube.com/watch?v=EQA69dvkQIk&list=PLBkR
The Core language is GHC's central data types. Core is a very small, explicitly-typed, variant of System F. The exact variant is called [System FC](commentary/compiler/fc), which embodies equality constraints and coercions.
The `CoreSyn` type, and the functions that operate over it, gets an entire directory [compiler/coreSyn](/trac/ghc/browser/ghc/compiler/coreSyn):
The `CoreSyn` type, and the functions that operate over it, gets an entire directory [compiler/coreSyn](/ghc/ghc/tree/master/ghc/compiler/coreSyn):
- [compiler/coreSyn/CoreSyn.hs](/trac/ghc/browser/ghc/compiler/coreSyn/CoreSyn.hs): the data type itself.
- [compiler/coreSyn/CoreSyn.hs](/ghc/ghc/tree/master/ghc/compiler/coreSyn/CoreSyn.hs): the data type itself.
- [compiler/coreSyn/PprCore.hs](/trac/ghc/browser/ghc/compiler/coreSyn/PprCore.hs): pretty-printing.
- [compiler/coreSyn/CoreFVs.hs](/trac/ghc/browser/ghc/compiler/coreSyn/CoreFVs.hs): finding free variables.
- [compiler/coreSyn/CoreSubst.hs](/trac/ghc/browser/ghc/compiler/coreSyn/CoreSubst.hs): substitution.
- [compiler/coreSyn/CoreUtils.hs](/trac/ghc/browser/ghc/compiler/coreSyn/CoreUtils.hs): a variety of other useful functions over Core.
- [compiler/coreSyn/PprCore.hs](/ghc/ghc/tree/master/ghc/compiler/coreSyn/PprCore.hs): pretty-printing.
- [compiler/coreSyn/CoreFVs.hs](/ghc/ghc/tree/master/ghc/compiler/coreSyn/CoreFVs.hs): finding free variables.
- [compiler/coreSyn/CoreSubst.hs](/ghc/ghc/tree/master/ghc/compiler/coreSyn/CoreSubst.hs): substitution.
- [compiler/coreSyn/CoreUtils.hs](/ghc/ghc/tree/master/ghc/compiler/coreSyn/CoreUtils.hs): a variety of other useful functions over Core.
- [compiler/coreSyn/CoreUnfold.hs](/trac/ghc/browser/ghc/compiler/coreSyn/CoreUnfold.hs): dealing with "unfoldings".
- [compiler/coreSyn/CoreUnfold.hs](/ghc/ghc/tree/master/ghc/compiler/coreSyn/CoreUnfold.hs): dealing with "unfoldings".
- [compiler/coreSyn/CoreLint.hs](/trac/ghc/browser/ghc/compiler/coreSyn/CoreLint.hs): type-check the Core program. This is an incredibly-valuable consistency check, enabled by the flag `-dcore-lint`.
- [compiler/coreSyn/CoreLint.hs](/ghc/ghc/tree/master/ghc/compiler/coreSyn/CoreLint.hs): type-check the Core program. This is an incredibly-valuable consistency check, enabled by the flag `-dcore-lint`.
- [compiler/coreSyn/CoreTidy.hs](/trac/ghc/browser/ghc/compiler/coreSyn/CoreTidy.hs): part of the [the CoreTidy pass](commentary/compiler/hsc-main) (the rest is in [compiler/main/TidyPgm.hs](/trac/ghc/browser/ghc/compiler/main/TidyPgm.hs)).
- [compiler/coreSyn/CorePrep.hs](/trac/ghc/browser/ghc/compiler/coreSyn/CorePrep.hs): [the CorePrep pass](commentary/compiler/hsc-main)
- [compiler/coreSyn/CoreTidy.hs](/ghc/ghc/tree/master/ghc/compiler/coreSyn/CoreTidy.hs): part of the [the CoreTidy pass](commentary/compiler/hsc-main) (the rest is in [compiler/main/TidyPgm.hs](/trac/ghc/browser/ghc/compiler/main/TidyPgm.hs)).
- [compiler/coreSyn/CorePrep.hs](/ghc/ghc/tree/master/ghc/compiler/coreSyn/CorePrep.hs): [the CorePrep pass](commentary/compiler/hsc-main)
Here is the entire Core type [compiler/coreSyn/CoreSyn.hs](/trac/ghc/browser/ghc/compiler/coreSyn/CoreSyn.hs):
Here is the entire Core type [compiler/coreSyn/CoreSyn.hs](/ghc/ghc/tree/master/ghc/compiler/coreSyn/CoreSyn.hs):
```wiki
type CoreExpr = Expr Var
......@@ -56,7 +56,7 @@ That's it. All of Haskell gets compiled through this tiny core.
If you want to learn more about such AST-parametrization, I encourage you to read a blog post about it: [http://blog.ezyang.com/2013/05/the-ast-typing-problem](http://blog.ezyang.com/2013/05/the-ast-typing-problem) .
Binder is used (as the name suggest) to bind a variable to an expression. The `Expr` data type is parametrized by the binder type. The most common one is the `type CoreBndr = Var` where `Var` comes from [compiler/basicTypes/Var.hs](/trac/ghc/browser/ghc/compiler/basicTypes/Var.hs), which in fact is a `Name` with some extra informations attached (like types).
Binder is used (as the name suggest) to bind a variable to an expression. The `Expr` data type is parametrized by the binder type. The most common one is the `type CoreBndr = Var` where `Var` comes from [compiler/basicTypes/Var.hs](/ghc/ghc/tree/master/ghc/compiler/basicTypes/Var.hs), which in fact is a `Name` with some extra informations attached (like types).
Here are some notes about the individual constructors of `Expr`.
......@@ -175,7 +175,7 @@ allowed. In other words, it is possible to come across a definition of a
variable that has the same name (`realUnique`) as some other one that is
already in scope. One of the possible ways to deal with that is to
use `Subst` (substitution environment from
[compiler/coreSyn/CoreSubst.hs](/trac/ghc/browser/ghc/compiler/coreSyn/CoreSubst.hs)), which maintains the list of
[compiler/coreSyn/CoreSubst.hs](/ghc/ghc/tree/master/ghc/compiler/coreSyn/CoreSubst.hs)), which maintains the list of
variables in scope and makes it possible to clone (i.e. rename) only the
variables that actually capture names of some earlier ones. For some more
explanations about this approach see
......@@ -185,4 +185,4 @@ explanations about this approach see
## Human readable Core generation
If you are interested in the way Core is translated into human readable form, you should check the sources for [compiler/coreSyn/PprCore.hs](/trac/ghc/browser/ghc/compiler/coreSyn/PprCore.hs). It is especially usefull if you want to see how the Core data types are being built, especially when there is no Show instance defined for them.
If you are interested in the way Core is translated into human readable form, you should check the sources for [compiler/coreSyn/PprCore.hs](/ghc/ghc/tree/master/ghc/compiler/coreSyn/PprCore.hs). It is especially usefull if you want to see how the Core data types are being built, especially when there is no Show instance defined for them.
......@@ -21,7 +21,7 @@ The structure of the Core-to-Core pipeline is determined in the `getCoreToDo` fu
- **Simplifier, gentle run**
- **Specialisation**: specialisation attempts to eliminate overloading. More details can be found in the comments in [compiler/specialise/Specialise.hs](/trac/ghc/browser/ghc/compiler/specialise/Specialise.hs).
- **Specialisation**: specialisation attempts to eliminate overloading. More details can be found in the comments in [compiler/specialise/Specialise.hs](/ghc/ghc/tree/master/ghc/compiler/specialise/Specialise.hs).
- **Full laziness, 1st pass**: floats let-bindings outside of lambdas. This pass includes annotating bindings with level information and then running the float-out pass. In this first pass of the full laziness we don't float partial applications and bindings that contain free variables - this will be done by the second pass later in the pipeline. See "Further Reading" section below for pointers where to find the description of the full laziness algorithm.
......@@ -29,7 +29,7 @@ The structure of the Core-to-Core pipeline is determined in the `getCoreToDo` fu
- **Float in, 1st pass**: the opposite of full laziness, this pass floats let-bindings as close to their use sites as possible. It will not undo the full laziness by sinking bindings inside a lambda, unless the lambda is one-shot. At this stage we have not yet run the demand analysis, so we only have demand information for things that we imported.
- **Call arity**: attempts to eta-expand local functions based on how they are used. If run, this pass is followed by a 0 phase of the simplifier. See Notes in [compiler/simplCore/CallArity.hs](/trac/ghc/browser/ghc/compiler/simplCore/CallArity.hs) and the relevant paper.
- **Call arity**: attempts to eta-expand local functions based on how they are used. If run, this pass is followed by a 0 phase of the simplifier. See Notes in [compiler/simplCore/CallArity.hs](/ghc/ghc/tree/master/ghc/compiler/simplCore/CallArity.hs) and the relevant paper.
- **Demand analysis, 1st pass** (a.k.a. strictness analysis): runs the [demand analyser](commentary/compiler/demand) followed by worker-wrapper transformation ([JFP paper](http://ittc.ku.edu/~andygill/papers/wrapper.pdf)) and 0 phase of the simplifier. This pass tries to determine if some expressions are certain to be used and whether they will be used once or many times (cardinality analysis). We currently don't have means of saying that a binding is certain to be used many times. We can only determine that it is certain to be one-shot (ie. used only once) or probable to be one shot. Demand analysis pass only annotates Core with strictness information. This information is later used by worker/wrapper pass to perform transformations. CPR analysis is also done during demand analysis.
......
......@@ -13,12 +13,12 @@ This discussion is going to omit concerns related to dynamic code loading in GHC
## The overall driver
The meat of this logic is in [compiler/main/GhcMake.hs](/trac/ghc/browser/ghc/compiler/main/GhcMake.hs), with primary entry point the function `load` (in the case of `--make`, this function is called with `LoadAllTargets`, instructing all target modules to be compiled, which is stored in `hsc_targets`).
The meat of this logic is in [compiler/main/GhcMake.hs](/ghc/ghc/tree/master/ghc/compiler/main/GhcMake.hs), with primary entry point the function `load` (in the case of `--make`, this function is called with `LoadAllTargets`, instructing all target modules to be compiled, which is stored in `hsc_targets`).
### Dependency analysis
Dependency analysis is carried out by the `depanal` function; the resulting `ModuleGraph` is stored into `hsc_mod_graph`. Essentially, this pass looks at all of the imports of the target modules (`hsc_targets`), and recursively pulls in all of their dependencies (stopping at package boundaries.) The resulting module graph consists of a list of `ModSummary` (defined in [compiler/main/HscTypes.hs](/trac/ghc/browser/ghc/compiler/main/HscTypes.hs)), which record various information about modules prior to compilation (recompilation checking, even), such as their module identity (the current package name plus the module name), whether or not the file is a boot file, where the source file lives. Dependency analysis inside GHC is often referred to as **downsweep**.
Dependency analysis is carried out by the `depanal` function; the resulting `ModuleGraph` is stored into `hsc_mod_graph`. Essentially, this pass looks at all of the imports of the target modules (`hsc_targets`), and recursively pulls in all of their dependencies (stopping at package boundaries.) The resulting module graph consists of a list of `ModSummary` (defined in [compiler/main/HscTypes.hs](/ghc/ghc/tree/master/ghc/compiler/main/HscTypes.hs)), which record various information about modules prior to compilation (recompilation checking, even), such as their module identity (the current package name plus the module name), whether or not the file is a boot file, where the source file lives. Dependency analysis inside GHC is often referred to as **downsweep**.
ToDo: say something about how hs-boot files are
......@@ -43,7 +43,7 @@ ToDo: say something about stability; it's per SCC
Compilation, also known as **upsweep**, walks the module graph in topological order and compiles everything. Depending on whether or not we are doing parallel compilation, this implemented by `upsweep` or by `parUpsweep`. In this section, we'll talk about the sequential upsweep.
The key data structure which we are filling in as we perform compilation is the **home package table** or HPT (`hsc_HPT`, defined in [compiler/main/HscTypes.hs](/trac/ghc/browser/ghc/compiler/main/HscTypes.hs)). As its name suggests, it contains informations from the \*home package\*, i.e. the package we are currently compiling. Its entries, `HomeModInfo`, contain the sum total knowledge of a module after compilation: both its pre-linking interface `ModIface` as well as the post-linking details `ModDetails`.
The key data structure which we are filling in as we perform compilation is the **home package table** or HPT (`hsc_HPT`, defined in [compiler/main/HscTypes.hs](/ghc/ghc/tree/master/ghc/compiler/main/HscTypes.hs)). As its name suggests, it contains informations from the \*home package\*, i.e. the package we are currently compiling. Its entries, `HomeModInfo`, contain the sum total knowledge of a module after compilation: both its pre-linking interface `ModIface` as well as the post-linking details `ModDetails`.
We \*clear\* out the home package table in the session (for `--make`, this was empty anyway), but we pass in the old HPT.
......
......@@ -15,7 +15,7 @@ For each kind of Haskell entity (identifier, type variable, type constructor, da
All of these entities have a `Name`, but that's about all they have in common. However they are sometimes treated uniformly: