RE: Converting unboxed sum types in StgCmm

ds2 is the thing that contains either an Int or a char; ds1 is the tag that distinguishes htem. Simon From: Johan Tibell [mailto:johan.tib...@gmail.com] Sent: 14 September 2015 17:03 To: Ryan Newton; Simon Peyton Jones Cc: Simon Marlow; ghc-devs@haskell.org Subject: Re: Converting unboxed sum

Re: Converting unboxed sum types in StgCmm

-> > > > > ds2 is the thing that contains either an Int or a char; ds1 is the tag > that distinguishes htem. > > > > Simon > > > > *From:* Johan Tibell [mailto:johan.tib...@gmail.com] > *Sent:* 14 September 2015 17:03 > *To:* Ryan Newton; Simo

Re: Converting unboxed sum types in StgCmm

> >> SImon >> >> *From:*Johan Tibell [mailto:johan.tib...@gmail.com] >> *Sent:* 09 September 2015 23:22 >> *To:* Simon Peyton Jones; Simon Marlow; ghc-devs@haskell.org >> *Subject:* Converting unboxed sum types in StgCmm >> >> Hi! >> >>

Re: Converting unboxed sum types in StgCmm

> > >- >data RepType = UbxTupleRep [UnaryType] >| UbxSumRep [UnaryType] >| UnaryRep UnaryType > > Not, fully following, but ... this reptype business is orthogonal to whether you add a normal type to the STG level that models anonymous, untagged unions, right? That is,

Re: Converting unboxed sum types in StgCmm

. Detailed type info >>> like “are you a Char or a Bool” is strictly jam; indeed never used I >>> think. (I could be wrong but I’m pretty sure I’m not wrong in a >>> fundamental way. >>> >> >> Yes, the only thing the code generator needs to do with

Re: Converting unboxed sum types in StgCmm

I've given this a yet some more thought. Given this simple core program: f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int [GblId, Arity=1, Str=DmdType] f = \ (ds_dmE :: (#|#) Int Char) -> case ds_dmE of _ [Occ=Dead] { (#_|#) x_amy -> x_amy; (#|_#) ipv_smK -> patError @ Int

Re: Converting unboxed sum types in StgCmm

> > It seems to me that we just want to rewrite the case altogether into > something that looks at the tag field of the data constructor. Also, in stg > we use the same DataCon as in core, but after stg the unboxed sum case > really only has one constructor (one with the union of all the fields),

Re: Converting unboxed sum types in StgCmm

have the same PrimRep (PtrRep). Cheers Simon SImon *From:*Johan Tibell [mailto:johan.tib...@gmail.com] *Sent:* 09 September 2015 23:22 *To:* Simon Peyton Jones; Simon Marlow; ghc-devs@haskell.org *Subject:* Converting unboxed sum types in StgCmm Hi! The original idea for implementing

RE: Converting unboxed sum types in StgCmm

” is strictly jam; indeed never used I think. (I could be wrong but I’m pretty sure I’m not wrong in a fundamental way. SImon From: Johan Tibell [mailto:johan.tib...@gmail.com] Sent: 09 September 2015 23:22 To: Simon Peyton Jones; Simon Marlow; ghc-devs@haskell.org Subject: Converting unboxed sum

Re: Converting unboxed sum types in StgCmm

ll [mailto:johan.tib...@gmail.com] > *Sent:* 09 September 2015 23:22 > *To:* Simon Peyton Jones; Simon Marlow; ghc-devs@haskell.org > *Subject:* Converting unboxed sum types in StgCmm > > > > Hi! > > > > The original idea for implementing the backend part of

Converting unboxed sum types in StgCmm

Hi! The original idea for implementing the backend part of the unboxed sums proposal was to convert from the core representation to the actual data representation (i.e. a tag followed by some pointer and non-pointer fields) in the unarise stg-to-stg

Re: Converting unboxed sum types in StgCmm

I wonder if rewriting any aliased pointer field as Any in Stg and any non-pointer field as Word# would work. I suspect that not all non-pointer fields (e.g. Double# on 32-bit) can be represented as Word#. On Wed, Sep 9, 2015 at 3:22 PM, Johan Tibell wrote: > Hi! > > The

Re: Converting unboxed sum types in StgCmm

Some of the SSE types are too big for that even on 64 bit, I think. Like DoubleX8#. On Thu, Sep 10, 2015 at 1:16 AM, Johan Tibell wrote: > I wonder if rewriting any aliased pointer field as Any in Stg and any > non-pointer field as Word# would work. I suspect that not all