I've rebased the diff and relaxed the assertion - do take a look if that looks reasonable to you :) https://phabricator.haskell.org/D4475
Cheers! - Michal On Wed, Jul 25, 2018 at 9:03 PM Michal Terepeta <[email protected]> wrote: > 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 < > [email protected]> 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#L2541 >> 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#L2764-L2774 >> >> 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 <[email protected]> >> 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/PrimFFIInt8.hs) >>> 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#L2764 >>> >>> 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 < >>> [email protected]> 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 < >>>> [email protected]> 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 <[email protected]> >>>>> 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 < >>>>>> [email protected]> 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 <[email protected]> >>>>>>> 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:Word-35-> >>>>>>> -> Word64X2# >>>>>>> <https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:Word64X2-35-> >>>>>>> which >>>>>>> should rather be broadcastWord64X2# :: Word64# >>>>>>> <https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:Word-35-> >>>>>>> -> Word64X2# >>>>>>> <https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:Word64X2-35-> >>>>>>> >>>>>>> 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-333951559 >>>>>>> >>>>>>> Thanks, >>>>>>> Abhiroop >>>>>>> >>>>>>> On Mon, May 28, 2018 at 6:06 PM, Michal Terepeta < >>>>>>> [email protected]> 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 < >>>>>>>> [email protected]> 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! >>> >>
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
