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

Moritz Angermann moritz.angermann at gmail.com
Sat Sep 26 12:39:28 UTC 2020


Luite is currently working on unboxed tuple support in the interpreter.
This will also be limited, as getting a generic solution for arbitrary
sized tuples raises a lot of complications.

Thus form a practical point of view, I’d go for (1) ;-)

We’ll need to rethink and get SIMD proper support at some point though, the
lack of such is rather sad.

On Sat, 26 Sep 2020 at 8:27 PM, 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
>>
>>
>>
>
> _______________________________________________
>
> 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/42f54812/attachment.html>


More information about the ghc-devs mailing list