diff options
author | Rodrigo Mesquita <rodrigo.m.mesquita@gmail.com> | 2023-05-05 15:02:35 +0100 |
---|---|---|
committer | Rodrigo Mesquita <rodrigo.m.mesquita@gmail.com> | 2023-05-16 14:59:09 +0100 |
commit | 9048ced72ac1d8642990dc64ac7b2aebf1c0bea4 (patch) | |
tree | 96f7550a1e529cca917755bcb732e6f8d765f48c /compiler/GHC/Stg/Syntax.hs | |
parent | b938a8efe56ed77e520a1df206f82ec7133f0e60 (diff) | |
download | haskell-wip/T23146.tar.gz |
Merge outdated Note [Data con representation] into Note [Data constructor representation]wip/T23146
Introduce new Note [Constructor applications in STG] to better support
the merge, and reference it from the relevant bits in the STG syntax.
Diffstat (limited to 'compiler/GHC/Stg/Syntax.hs')
-rw-r--r-- | compiler/GHC/Stg/Syntax.hs | 50 |
1 files changed, 48 insertions, 2 deletions
diff --git a/compiler/GHC/Stg/Syntax.hs b/compiler/GHC/Stg/Syntax.hs index f18a25beb8..7ddf7fef3b 100644 --- a/compiler/GHC/Stg/Syntax.hs +++ b/compiler/GHC/Stg/Syntax.hs @@ -237,6 +237,52 @@ StgConApp and StgPrimApp --- saturated applications There are specialised forms of application, for constructors, primitives, and literals. + +Note [Constructor applications in STG] +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +After the unarisation pass: +* In `StgConApp` and `StgRhsCon` and `StgAlt` we filter out the void arguments, + leaving only non-void ones. +* In `StgApp` and `StgOpApp` we retain void arguments. + +We can do this because we know that `StgConApp` and `StgRhsCon` are saturated applications, +so we lose no information by dropping those void args. In contrast, in `StgApp` we need the + void argument to compare the number of args in the call with the arity of the function. + +This is an open design choice. We could instead choose to treat all these applications +consistently (keeping the void args). But for some reason we don't, and this Note simply +documents that design choice. + +As an example, consider: + + data T a = MkT Int! a Void# + +The wrapper's representation and the worker's representation (i.e. the +datacon's Core representation) are respectively: + + $WT :: Int -> a -> Void# -> T a + T :: Int# -> a -> Void# -> T a + +T would end up being used in STG post-unarise as: + + let x = T 1# y + in ... + case x of + T int a -> ... + +The Void# argument is dropped. In essence we only generate binders for runtime +relevant values. + +We also flatten out unboxed tuples in this process. See the unarise +pass for details on how this is done. But as an example consider +`data S = MkS Bool (# Bool | Char #)` which when matched on would +result in an alternative with three binders like this + + MkS bool tag tpl_field -> + +See Note [Translating unboxed sums to unboxed tuples] and Note [Unarisation] +for the details of this transformation. + -} | StgLit Literal @@ -245,7 +291,7 @@ literals. -- which can't be let-bound | StgConApp DataCon ConstructorNumber - [StgArg] -- Saturated. (After Unarisation, [NonVoid StgArg]) + [StgArg] -- Saturated. See Note [Constructor applications in STG] [Type] -- See Note [Types in StgConApp] in GHC.Stg.Unarise | StgOpApp StgOp -- Primitive op or foreign call @@ -422,7 +468,7 @@ important): -- are not allocated. ConstructorNumber [StgTickish] - [StgArg] -- Args + [StgArg] -- Saturated Args. See Note [Constructor applications in STG] Type -- Type, for rewriting to an StgRhsClosure -- | Like 'GHC.Hs.Extension.NoExtField', but with an 'Outputable' instance that |