summaryrefslogtreecommitdiff
path: root/compiler/GHC/Stg/Syntax.hs
diff options
context:
space:
mode:
authorRodrigo Mesquita <rodrigo.m.mesquita@gmail.com>2023-05-05 15:02:35 +0100
committerRodrigo Mesquita <rodrigo.m.mesquita@gmail.com>2023-05-16 14:59:09 +0100
commit9048ced72ac1d8642990dc64ac7b2aebf1c0bea4 (patch)
tree96f7550a1e529cca917755bcb732e6f8d765f48c /compiler/GHC/Stg/Syntax.hs
parentb938a8efe56ed77e520a1df206f82ec7133f0e60 (diff)
downloadhaskell-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.hs50
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