Re: understanding assertions, part deux :) Re: whither built in unlifted Word32# / Word64# etc?

Hi Carter, I didn't write this assertion. I only validated locally (IIRC at the time I uploaded the diff, harbormaster was failing for some other reasons). I'll try to have a look at it this weekend. Cheers! - Michal On Wed, Jul 25, 2018 at 2:16 AM Carter Schonwald wrote:

Michal: did you write this Assert about width? and if so could you explain it so we can understand?

hrmm... that code is in the procedure for generating C calls for 64bit intel systems

https://github.com/michalt/ghc/blob/int8/compiler/nativeGen/X86/CodeGen.hs#L... is the top of that routine

and width is defined right below the spot in question

https://github.com/michalt/ghc/blob/int8/compiler/nativeGen/X86/CodeGen.hs#L...

it seems like the code/assertion likely predates michal's work? (eg, a trick to make sure that genCCall64 doesn't get invoked by 32bit platforms?)

On Mon, Jul 23, 2018 at 8:54 PM Abhiroop Sarkar wrote:

...

Hi Michal,

In the tests that you have added to D4475, are all the tests running fine?

On my machine, I was running the FFI tests( https://github.com/michalt/ghc/blob/int8/testsuite/tests/ffi/should_run/Prim...) and they seem to fail at a particular assert statement in the code generator.

To be precise this one: https://github.com/michalt/ghc/blob/int8/compiler/nativeGen/X86/CodeGen.hs#L...

Upon commenting that assert the tests run fine. Am I missing something or is the failure expected?

Thanks, Abhiroop

On Mon, Jul 9, 2018 at 8:31 PM Michal Terepeta wrote:

...

Just for the record, I've uploaded the changes to binary: https://github.com/michalt/packages-binary/tree/int8

- Michal

On Wed, Jul 4, 2018 at 11:07 AM Michal Terepeta < michal.terepeta@gmail.com> wrote:

...

Yeah, if you look at the linked diff, there are a few tiny changes to binary that are necessary.

I'll try to upload them to github later this week.

Ben, is something blocking the review of the diff? I think I addressed all comments so far.

- Michal

On Wed, Jul 4, 2018 at 1:38 AM Abhiroop Sarkar wrote:

...

Hello Michal,

I was looking at your diff https://phabricator.haskell.org/D4475 and there seems to be some changes that you perhaps made in the binary package ( https://phabricator.haskell.org/differential/changeset/?ref=199152&whitespace=ignore-most). I could not find your version of binary on your github repos list. Is it possible for you to upload that so I can pull those changes?

Thanks

Abhiroop

On Mon, May 28, 2018 at 10:45 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

Abhiroop has the gist, though the size of word args for simd is more something we want to be consistent between 32/64 bit modes aka ghc targeting 32 or 64 bit intel with simd support :). It would be best if the unpack and pack operations that map to and from unboxed tuples where consistent and precise type wise.

-Carter

On May 28, 2018, at 5:02 PM, Abhiroop Sarkar wrote:

Hello Michal,

My understanding of the issues are much lesser compared to Carter. However, I will state whatever I understood from discussions with him. Be warned my understanding might be wrong and Carter might be asking this for some completely different reason.

> Out of curiosity, why do you need Word64#/Word32# story to be fixed for SIMD?

One of the issues we are dealing with is multiple microarchitectures(SSE, AVX, AVX2 etc). As a result different microarchitectures has different ways of handling an 8 bit or 16 bit or 32 bit unsigned integer. An example I can provide is the vector multiply instruction which has different semantics of multiplying and storing the first 16 bits of a 32 bit unsigned integer compared to the lower 16 bits for each of the elements in its SIMD registers. There will be some other intricacies around handling a byte sized integer or a 64 bit integer which will be different from the 32 bit version.

Basically a 128 bit vector instruction will make some minor differences when dealing with 2 64 bit integers or 4 32 bit integer or 8 16 bit integers.

So I think at the higher level we would want to be as precise as possible when specifying the datatypes and want things like Word8#, Word16#, Word32#, Word64# rather than a single ambiguous type like Word.

One more example is this vector operation like : broadcastWord64X2# :: Word# https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:Wo... -> Word64X2# https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:Wo... which should rather be broadcastWord64X2# :: Word64# https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:Wo... -> Word64X2# https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:Wo...

Another reason could be improving the space efficiency of packing various datatypes. This was explained in some detail in this comment: https://github.com/ghc-proposals/ghc-proposals/pull/74#issuecomment-33395155...

Thanks, Abhiroop

On Mon, May 28, 2018 at 6:06 PM, Michal Terepeta < michal.terepeta@gmail.com> wrote:

> Hey Carter, > > Yeah, I'm totally snowed under with personal stuff at the moment, so > not much time to hack on > anything. I've managed to make some progress on > https://phabricator.haskell.org/D4475 (prototype > that adds Int8#/Word8#; waiting for another round of review). Sadly > June still looks a bit crazy for > me, so I can't promise anything for Word64#/Word32# (and > Int64#/Int32#). I hope to have some more > time in July. > > If this is blocking you, then please don't wait for me and go ahead > (my diff for Int8#/Word8# might > be a decent starting point to see which places might need changes). > > Out of curiosity, why do you need Word64#/Word32# story to be fixed > for SIMD? Cmm already has > separate types for vector types (see TyCon.hs and VecRep constructor > of PrimRep). > > Cheers! > > - Michal > > PS. Are you coming to ZuriHac by any chance? > > On Mon, May 28, 2018 at 12:37 AM Carter Schonwald < > carter.schonwald@gmail.com> wrote: > >> Hey Michal! >> So i'm mentoring Abhiroop around getting SIMD all nice and awesome, >> and I realized we still dont quite yet have the nice Word32# and Word64# >> etc story in ghc as yet. >> >> Whats the status on that and or is there a way we can help get that >> over the hump for ghc? These different sized in register ints and friends >> have a tight partnership with any nice SIMD iterating over the summer, and >> hopefully helps inform the design >> >> -Carter >> >

-- Kloona - Coming Soon!

-- Kloona - Coming Soon!

-- Kloona - Coming Soon!