How is GHC.Prim.unpackInt8X64# meant to be used?

[Moritz Angermann]

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

On Sat, Sep 26, 2020 at 8:52 PM Ben Gamari <ben at 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 at 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.
>> -----
>> [1]
>> https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/libraries/ghc-prim/GHC/Tuple.hs#L170
>>
>> On Sat, Sep 26, 2020 at 7:54 AM Ben Gamari <ben at smart-cactus.org> wrote:
>>
>>> On September 25, 2020 6:21:23 PM EDT, Ryan Scott <
>>> ryan.gl.scott at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200926/f3e98ea4/attachment.html>