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.sc...@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 <b...@smart-cactus.org> wrote: > >> On September 25, 2020 6:21:23 PM EDT, Ryan Scott <ryan.gl.sc...@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@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
