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

[Michal Terepeta]

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 <michal.terepeta at gmail.com>
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 <
> carter.schonwald at 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 <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/20180801/4f2aa2e6/attachment.html>