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 <carter.schonw...@gmail.com> 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 <asiamgen...@gmail.com> > 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 <michal.terep...@gmail.com> >> 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.terep...@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 <asiamgen...@gmail.com> >>>> 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.schonw...@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 <asiamgen...@gmail.com> >>>>>> 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 < >>>>>> michal.terep...@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.schonw...@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! >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs