<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
.MsoPapDefault
{mso-style-type:export-only;
margin-top:6.0pt;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hmm. It’s not clear to me why we have *<b>any</b>* limitation on the size of unboxed tuples.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><br>
For boxed tuples I know: we need an info table, code etc. But not so for unboxed.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Why do we need a limit at all?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-devs <ghc-devs-bounces@haskell.org>
<b>On Behalf Of </b>Ryan Scott<br>
<b>Sent:</b> 25 September 2020 23:21<br>
<b>To:</b> GHC developers <ghc-devs@haskell.org><br>
<b>Subject:</b> How is GHC.Prim.unpackInt8X64# meant to be used?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
GHC imposes an upper bound of 62 on the size of tuples one can use [1]. Currently, this upper bound applies to both boxed and unboxed tuples alike. For example, if you try to create an unboxed tuple of arity 64, then GHC will throw an error:<br>
<br>
error:<br>
A 64-tuple is too large for GHC<br>
(max size is 62)<br>
Workaround: use nested tuples or define a data type<br>
|<br>
| f = (#,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,#)<br>
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
<br>
However, I discovered recently that there are places where GHC *does* use unboxed tuples with arity greater than 62. For example, the GHC.Prim.unpackInt8X64# [2] function returns an unboxed tuple of size 64. I was confused for a while about how this was even
possible, but I realized later than GHC only enforces the tuple size limit in expressions and patterns [3]. Simply having a type signature with a large unboxed tuple is fine in and of itself, and since unpackInt8X64# is implemented as a primop, no large unboxed
tuples are ever used in the "body" of the function. (Indeed, primops don't have function bodies in the conventional sense.) Other functions in GHC.Prim that use unboxed tuples of arity 64 include unpackWord8X64# [4], packInt8X64# [5], and packWord8X64# [6].<br>
<br>
But this makes me wonder: how on earth is it even possible to *use* unpackInt8X64#? The only thing that comes to mind is to pattern-match on the unboxed tuple that it returns, but if you try to do that, you'll get a "64-tuple is too large for GHC" error like
shown above. What's more, I can't find any test cases in the GHC test suite that show how unpackInt8X64# or its cousins are supposed to be used. What am I missing? The comments for these functions mention "Warning: this is only available on LLVM", so perhaps
someone familiar with the LLVM backend knows what the answer is?<br>
<br>
For some context, this came up in !4097, where I am attempting to extend the "too large for GHC" error message to include types, in addition to expressions and patterns [7]. However, doing so causes Haddock to error when processing unpackInt8X64# et al.<br>
<br>
Ryan S.<br>
-----<br>
[1] <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fblob%2Fa1f34d37b47826e86343e368a5c00f1a4b1f2bce%2Fcompiler%2FGHC%2FSettings%2FConstants.hs%23L13-15&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218050286&sdata=LAb06t4YCkyQgSfp3si07unb0sEW3vE7pEHRbzUxKZU%3D&reserved=0">
https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/compiler/GHC/Settings/Constants.hs#L13-15</a>
<br>
[2] <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-prim-0.6.1%2Fdocs%2FGHC-Prim.html%23v%3AunpackInt8X64-35-&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218060277&sdata=eC52wb5dTfzVVAgJLMc428av%2FDgY9NyqyMCROfkD6ro%3D&reserved=0">
https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:unpackInt8X64-35-</a><br>
[3] <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F18723&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218070276&sdata=VRucYwSTbGD1iD9KhJst2ZTmsuZ%2BQdwKTyivnTqKBm4%3D&reserved=0">
https://gitlab.haskell.org/ghc/ghc/-/issues/18723</a><br>
[4] <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-prim-0.6.1%2Fdocs%2FGHC-Prim.html%23v%3AunpackWord8X64-35-&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218070276&sdata=3naSYWb5y2SpznOO0y4ip9Pd3hzzmbSuBWViCPbM%2FAU%3D&reserved=0">
https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:unpackWord8X64-35-</a><br>
[5] <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-prim-0.6.1%2Fdocs%2FGHC-Prim.html%23v%3ApackInt8X64-35-&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218080272&sdata=QpdcjMe1gN91NJAPzTjdksFFXR3sibl5bZqhd23f6Hc%3D&reserved=0">
https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:packInt8X64-35-</a><br>
[6] <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-prim-0.6.1%2Fdocs%2FGHC-Prim.html%23v%3ApackWord8X64-35-&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218090268&sdata=x9%2FqCgRRALtH4%2B7wTK9hqxk%2FrhIqSs%2BPwIk%2BjQlljsY%3D&reserved=0">
https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:packWord8X64-35-</a><br>
[7] <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F4097%23note_301191&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218090268&sdata=oGUSsN7bwBLV9p7MchpSfQH4dtjWm6apaumIM1IGg2Q%3D&reserved=0">
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4097#note_301191</a><o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>