Ryan, the comment in GHC.Tuple seems to be misleading today, as suggested by this SO post: https://stackoverflow.com/questions/46412823/why-are-ghc-tuples-limited-to-s...
I was going to add it to the comment at some point but was hesitant as I hadn’t verified the information myself.
V
On 26 Sep 2020, at 14:26, Ryan Scott
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].
But this makes me wonder: how on earth is it even possible to *use* unpackInt8X64#?
I strongly suspect that the answer here is "you can't yet no one has noticed until now." The SIMD operations were essentially introduced as a technology preview and therefore never had proper tests added. Only a subset of these operations have any tests at all and I doubt anyone has attempted to use the 64-wide operations, which are rather specialized. Cheers, - Ben _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs