I think as long as it's bounded it's ok. On Sat, Sep 26, 2020 at 8:52 PM Ben Gamari <b...@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.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 >>> >> > -- > 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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
