I think as long as it's bounded it's ok.

On Sat, Sep 26, 2020 at 8:52 PM Ben Gamari <ben@well-typed.com> wrote:
I think it would be worth trying to add tuples up to width 64. The only real cost here is the interface file size of GHC.Tuple and if adding a 63-wide tuple really does induce a crash then that is a bug in its own right that deserves investigation.

- Ben

On September 26, 2020 8:26:32 AM EDT, Ryan Scott <ryan.gl.scott@gmail.com> wrote:
I had a feeling that this might be the case. Unfortunately, this technology preview is actively blocking progress on !4097, which leaves me at a loss for what to do. I can see two ways forward:

1. Remove unpackInt8X64# and friends.
2. Reconsider whether the tuple size limit should apply to unboxed tuples. Perhaps this size limit only makes sense for boxed tuples? This comment [1] suggests that defining a boxed tuple of size greater than 62 induces a segfault, but it's unclear to me if the same thing happens for unboxed tuples.

Ryan S.
-----

On Sat, Sep 26, 2020 at 7:54 AM Ben Gamari <ben@smart-cactus.org> wrote:
On September 25, 2020 6:21:23 PM EDT, Ryan Scott <ryan.gl.scott@gmail.com> wrote:
...
>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

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs