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

Wed Jul 25 00:16:04 UTC 2018

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 <asiamgenius at 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.terepeta at 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.terepeta at 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 <asiamgenius at 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.schonwald at 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 <asiamgenius at 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.terepeta at 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 at 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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180724/097cc670/attachment.html>