Commit f44c17be authored by Sylvain Henry's avatar Sylvain Henry

StgToCmm renamings after #13009

parent 9c329377
......@@ -1204,7 +1204,7 @@ The computed procedure address, in this case `(bits32[x+4])`, should always be t
`CmmCondBranch CmmExpr BlockId` represents a conditional branch to another [Basic Block](commentary/compiler/cmm-type#basic-blocks-and-procedures) in the same procedure. This is the `if expr` statement where `expr` is a `CmmExpr`, used in both the unary `if` and `if-then-else` statements. `CmmCondBranch` maps to more complex Assembler instruction sets or HC code ([compiler/cmm/PprC.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/cmm/PprC.hs)). For assembler, labels are created for each new Basic Block. During parsing, conditional statements map to the `BoolExpr` data type which guides the encoding of assembler instruction sets.
`CmmSwitch` represents the `switch` statement. It is parsed and created as with the `doSwitch` function in [compiler/cmm/CmmParse.y](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/cmm/CmmParse.y) or created from `case` expressions with the `emitSwitch` and `mk_switch` functions in [compiler/codeGen/CgUtils.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/codeGen/CgUtils.hs). In the NCG, a `CmmSwitch` is generated as a jump table using the `genSwitch` function in [compiler/nativeGen/MachCodeGen.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/nativeGen/MachCodeGen.hs). There is currently no implementation of any optimisations, such as a cascade of comparisons for switches with a wide deviation in values or binary search for very wide value ranges--for output to HC, earlier versions of GCC could not handle large if-trees, anyway.
`CmmSwitch` represents the `switch` statement. It is parsed and created as with the `doSwitch` function in [compiler/cmm/CmmParse.y](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/cmm/CmmParse.y) or created from `case` expressions with the `emitSwitch` and `mk_switch` functions in [compiler/GHC/StgToCmm/CgUtils.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/GHC/StgToCmm/CgUtils.hs). In the NCG, a `CmmSwitch` is generated as a jump table using the `genSwitch` function in [compiler/nativeGen/MachCodeGen.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/nativeGen/MachCodeGen.hs). There is currently no implementation of any optimisations, such as a cascade of comparisons for switches with a wide deviation in values or binary search for very wide value ranges--for output to HC, earlier versions of GCC could not handle large if-trees, anyway.
#### Cmm Calls
......
......@@ -9,7 +9,7 @@ The goal of the code generator is to convert program from [STG](commentary/compi
The top-most entry point to the codegen is located in [compiler/main/HscMain.hs](https://gitlab.haskell.org/ghc/ghc/tree/master/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](https://gitlab.haskell.org/ghc/ghc/tree/master/compiler/codeGen) directory with the entry point being `codeGen` function in [compiler/codeGen/StgCmm.hs](https://gitlab.haskell.org/ghc/ghc/tree/master/compiler/codeGen/StgCmm.hs) module.
1. Convert STG to Cmm with implicit stack, and native Cmm calls. This whole stage lives in [compiler/codeGen](https://gitlab.haskell.org/ghc/ghc/tree/master/compiler/codeGen) directory with the entry point being `codeGen` function in [compiler/GHC/StgToCmm.hs](https://gitlab.haskell.org/ghc/ghc/tree/master/compiler/GHC/StgToCmm.hs) module.
1. Optimise the Cmm, and CPS-convert it to have an explicit stack, and no native calls. This lives in [compiler/cmm](https://gitlab.haskell.org/ghc/ghc/tree/master/compiler/cmm) directory with the `cmmPipeline` function from [compiler/cmm/CmmPipeline.hs](https://gitlab.haskell.org/ghc/ghc/tree/master/compiler/cmm/CmmPipeline.hs) module being the entry point.
......
## Historical page
This page stores historical information about Cmm Pipeline in the new code generator. This description has been updated and is maintained on the [Code Generator](commentary/compiler/code-gen) page. This page has also historical notes about Adams optimisation. That optimisation is also described in Note \[sharing continuations\] in [compiler/codeGen/StgCmmMonad.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/codeGen/StgCmmMonad.hs) and probably deserves its own wiki page.
This page stores historical information about Cmm Pipeline in the new code generator. This description has been updated and is maintained on the [Code Generator](commentary/compiler/code-gen) page. This page has also historical notes about Adams optimisation. That optimisation is also described in Note \[sharing continuations\] in [compiler/GHC/StgToCmm/Monad.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/GHC/StgToCmm/Monad.hs) and probably deserves its own wiki page.
# Design of the new code generator
......
......@@ -14,25 +14,7 @@ The new codegen was enabled by default in [832077ca5393d298324cb6b0a2cb501e27209
- Remove live-var and CAF lists from `StgSyn`, and then clean up `CoreToStg`
- DONE Remove the SRT pass in `simplStg/SRT.lhs`
- DONE remove RET_DYN from the RTS
- DONE remove `-fnew-codegen`, related `HscMain` bits and the `CodeGen` module.
- DONE remove `CmmOpt.cmmMiniInline`, it is not used any more
- Fix the layering: `cmm` modules should not depend on `codeGen/StgCmm*`
## Towards removing codeGen/Cg\*
- DONE `CmmParse` should produce new `Cmm`.
- We will probably want two kinds of `.cmm` file, one that is to be fed through `CmmLayoutStack` and one that isn't.
- primops will be fed through `CmmLayoutStack`, and will use the native calling convention, with the code generator inserting the copyin/copyout for us.
- DONE Remove all the `Cg*` modules
- Fix the layering: `GHC.Cmm.*` modules should not depend on `GHC.StgToCmm.*`
## Towards removing `OldCmm`
......
......@@ -17,9 +17,9 @@ Cost-center profiling in GHC, e.g. of SCCs, consists of the following components
- Data-structures for representing cost-centres in [compiler/profiling/CostCentre.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/profiling/CostCentre.hs).
- Front-end support in [compiler/deSugar/DsExpr.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/deSugar/DsExpr.hs), for converting `SCC` pragma into the `Tick` constructor in Core.
- Modifications to optimization behavior in [compiler/coreSyn/CoreUtils.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/coreSyn/CoreUtils.hs) and [compiler/coreSyn/CorePrep.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/coreSyn/CorePrep.hs) to prevent optimizations which would result in misleading profile information. Most of this is to handle the fact that SCCs also count entries (tickishCounts, also applies to [Commentary/Hpc](commentary/hpc)); otherwise the only relevant optimization is avoiding floating expressions out of SCCs. Note that the simplifier also has "ticks" (so it can decide when to stop optimizing); these are not the same thing at all.
- The `StgSCC` constructor in STG, and code generation for it [compiler/codeGen/StgCmmProf.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/codeGen/StgCmmProf.hs)
- The `StgSCC` constructor in STG, and code generation for it [compiler/GHC/StgToCmm/Prof.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/GHC/StgToCmm/Prof.hs)
- A pass over STG in [compiler/profiling/SCCfinal.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/profiling/SCCfinal.hs) to collect cost centres so that they can be statically declared by [compiler/profiling/ProfInit.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/profiling/ProfInit.hs), and add extra SCCs in the case of `-fprof-auto`; see also [compiler/profiling/NOTES](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/profiling/NOTES)
- Code-generation for setting labels found in [compiler/codeGen/StgCmmProf.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/codeGen/StgCmmProf.hs), in particular saving and restoring CC labels and well as counting ticks; note that cost-centres even get their own constructor in C-- as CC_Labels (cost-centre labels).
- Code-generation for setting labels found in [compiler/GHC/StgToCmm/Prof.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/GHC/StgToCmm/Prof.hs), in particular saving and restoring CC labels and well as counting ticks; note that cost-centres even get their own constructor in C-- as CC_Labels (cost-centre labels).
- Runtime support for initializing and manipulating the actual runtime `CostCentre` structs which store information, in [rts/Profiling.c](https://gitlab.haskell.org/ghc/ghc/blob/master/rts/Profiling.c); headers are located in [includes/rts/prof/CCS.h](https://gitlab.haskell.org/ghc/ghc/blob/master/includes/rts/prof/CCS.h)
## Ticky-ticky profiling
......
......@@ -10,7 +10,7 @@ Resource limits is a new way (similar to profiled and dynamic). Here are the rel
### Dynamic closure allocation
[compiler/codeGen/StgCmmHeap.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/codeGen/StgCmmHeap.hs):allocDynClosureCmm (via StgCmmCon, also handles StgCmmBind:mkRhsClosure/cgRhsStdThunk. link_caf needs special treatment.)
[compiler/GHC/StgToCmm/Heap.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/GHC/StgToCmm/Heap.hs):allocDynClosureCmm (via StgCmmCon, also handles StgCmmBind:mkRhsClosure/cgRhsStdThunk. link_caf needs special treatment.)
```wiki
// profDynAlloc rep use_cc
......@@ -40,7 +40,7 @@ I.e. no change from un-profiled.
### CAF Allocation
[compiler/codeGen/StgCmmBind.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/codeGen/StgCmmBind.hs):thunkCode
[compiler/GHC/StgToCmm/Bind.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/GHC/StgToCmm/Bind.hs):thunkCode
Here is an interesting bugger:
......@@ -145,7 +145,7 @@ We also hit the slow function application path.
### Thunk code
[compiler/codeGen/StgCmmBind.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/codeGen/StgCmmBind.hs):thunkCode
[compiler/GHC/StgToCmm/Bind.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/GHC/StgToCmm/Bind.hs):thunkCode
```wiki
// ldvEnterClosure cl_info
......
......@@ -350,7 +350,7 @@ When compiling with `-ticky`, the back-end emits the name-specific counters in t
The global counters are *always* statically allocated by the RTS [includes/stg/Ticky.h](https://gitlab.haskell.org/ghc/ghc/blob/master/includes/stg/Ticky.h) regardless of the compilation way.
Some `TICK_...` C-- macros are sprinkled throughout the RTS. In the debug way (cf `ways.mk`) `TICKY_TICKY` is `defined`, so these macros expand to code that ticks the counters. The relevant compiler code is mostly in [compiler/codeGen/StgCmmTicky.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/codeGen/StgCmmTicky.hs). NB that some of these macros are expanded by [compiler/cmm/CmmParse.y](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/cmm/CmmParse.y)!
Some `TICK_...` C-- macros are sprinkled throughout the RTS. In the debug way (cf `ways.mk`) `TICKY_TICKY` is `defined`, so these macros expand to code that ticks the counters. The relevant compiler code is mostly in [compiler/GHC/StgToCmm/Ticky.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/GHC/StgToCmm/Ticky.hs). NB that some of these macros are expanded by [compiler/cmm/CmmParse.y](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/cmm/CmmParse.y)!
The C-- macros are defined in [includes/Cmm.h](https://gitlab.haskell.org/ghc/ghc/blob/master/includes/Cmm.h). Most of them (probably all of them, at the moment) just increment counters (variables in C) that are declared in [includes/stg/Ticky.h](https://gitlab.haskell.org/ghc/ghc/blob/master/includes/stg/Ticky.h). The latter file is likely to get out of sync with the former, so it really should be automatically generated.
......
......@@ -30,7 +30,7 @@ I need to add *inline* primops since `addIntC#` & co. are all inline.
So, I only need to touch these files:
- `compiler/prelude/primops.txt.pp`
- `compiler/codeGen/StgCmmPrim.hs`
- `compiler/GHC/StgToCmm/Prim.hs`
There's also a tutorial on adding an *out-of-line* primop, but some
......@@ -41,7 +41,7 @@ bits of it may be useful (e.g., building GHC after making changes):
For `addIntC#`, it's done in the already mentioned
`compiler/codeGen/StgCmmPrim.hs` file:
`compiler/GHC/StgToCmm/Prim.hs` file:
```wiki
callishPrimOpSupported :: DynFlags -> PrimOp -> Either CallishMachOp GenericOp
......
......@@ -4,7 +4,7 @@ Starting with version 7.2, GHC has three new primitives for copying/setting bloc
## Implementation
The primitives are implemented as three [Cmm language](commentary/compiler/cmm-type) [CallishMachOp\`s](commentary/compiler/cmm-type#operators-and-primitive-operations), defined in [compiler/cmm/CmmMachOp.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/cmm/CmmMachOp.hs). The code generator generates calls to these `CallishMachOp`s using three utility functions: `emitMemcpyCall`, `emitMemmoveCall`, and `emitMemsetCall`, defined in [compiler/codeGen/StgCmmPrim.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/codeGen/StgCmmPrim.hs). The helper functions take an extra parameter that indicates the alignment of the arguments, which is used as an optimization hint by the backends.
The primitives are implemented as three [Cmm language](commentary/compiler/cmm-type) [CallishMachOp\`s](commentary/compiler/cmm-type#operators-and-primitive-operations), defined in [compiler/cmm/CmmMachOp.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/cmm/CmmMachOp.hs). The code generator generates calls to these `CallishMachOp`s using three utility functions: `emitMemcpyCall`, `emitMemmoveCall`, and `emitMemsetCall`, defined in [compiler/GHC/StgToCmm/Prim.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/GHC/StgToCmm/Prim.hs). The helper functions take an extra parameter that indicates the alignment of the arguments, which is used as an optimization hint by the backends.
The reason the primitives are unrolled in the backends, instead of in the code generator, is to allow us to make use of LLVM's `memcpy`/`memmove`/`memset` intrinsics, which LLVM optimizes well. In the x86/x86-64 backend we unroll the primitives ourselves. The different native code generator backends can also generate more efficient code than a generic case higher up. Currently only the X86 backend unrolls these primitives though, SPARC and !PowerPC both just call the corresponding C functions.
......@@ -56,7 +56,7 @@ These primitives aren't directly exposed to the user at this time. Instead the p
- `freezeArray#`
- `thawArray#`
The latter four allow the user to efficiently clone an array without first setting all elements to some dummy element, which would be required to e.g. implement `cloneArray#` in terms of `newArray#` and `copyArray#`. The implementation of these primitive operations are in [compiler/codeGen/StgCmmPrim.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/codeGen/StgCmmPrim.hs).
The latter four allow the user to efficiently clone an array without first setting all elements to some dummy element, which would be required to e.g. implement `cloneArray#` in terms of `newArray#` and `copyArray#`. The implementation of these primitive operations are in [compiler/GHC/StgToCmm/Prim.hs](https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/GHC/StgToCmm/Prim.hs).
## Test API
......
......@@ -71,10 +71,10 @@ Modifications to add support to the compiler for the new types. Look to individ
- ./compiler/codeGen/CgCallConv.hs
- ./compiler/codeGen/CgPrimOp.hs
- ./compiler/codeGen/CgUtils.hs
- ./compiler/GHC/StgToCmm/CgUtils.hs
- ./compiler/codeGen/SMRep.lhs
- ./compiler/codeGen/StgCmmLayout.hs
- ./compiler/codeGen/StgCmmPrim.hs
- ./compiler/GHC/StgToCmm/Layout.hs
- ./compiler/GHC/StgToCmm/Prim.hs
More modifications to the Cmm portion of the compiler chain.
......
......@@ -134,6 +134,6 @@ This would make a constructor with the given info table. The primop can tell ho
This list is likely to be non-exhaustive...
- Add primops, new primitive types (`prelude/primops.txt`, `prelude/TysPrim.lhs`)
- Implement primops, (`codeGen/CgPrimOp.lhs`, `codeGen/StgCmmPrim.lhs`)
- Add desugaring of unpacked array types in argument and field positions, and `indexUnpackedArray#` to `indexInteriorArray#` (somewhere under `desugar/` probably)
- Add code generation for case alternatives on constructors containing interior arrays, they have to bind variables to the `InteriorArrayContainer#` and offset (`codeGen/CgCase.lhs`, `codeGen/StgCmmCase.lhs`).
- Implement primops, (`GHC/StgToCmm/Prim.hs`)
- Add desugaring of unpacked array types in argument and field positions, and `indexUnpackedArray#` to `indexInteriorArray#` (somewhere under `GHC.HsToCore` probably)
- Add code generation for case alternatives on constructors containing interior arrays, they have to bind variables to the `InteriorArrayContainer#` and offset (`codeGen/StgCmmCase.hs`).
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment