understanding assertions, part deux :) Re: whither built in unlifted Word32# / Word64# etc?
Carter Schonwald
carter.schonwald at gmail.com
Thu Aug 2 03:37:49 UTC 2018
So the issue was core lint type error rather than a cmm lint error? Glad
you figured it out !
But you didn’t communicate what the error you got from lint was core rather
than cmm ... :(
On Wed, Aug 1, 2018 at 11:25 PM Abhiroop Sarkar <asiamgenius at gmail.com>
wrote:
> Never mind I found the issue and fixed it.
>
> It was the definition of the `Int32` type constructor:
>
> int32PrimTyCon = pcPrimTyCon0 int32PrimTyConName IntRep
>
> which had to be fixed to
>
> int32PrimTyCon = pcPrimTyCon0 int32PrimTyConName Int32Rep
>
> Thanks anyways :)
>
> Abhiroop
>
> On Wed, Aug 1, 2018 at 5:36 PM Abhiroop Sarkar <asiamgenius at gmail.com>
> wrote:
>
>> Hello,
>>
>> I would appreciate some help in debugging a Cmm Lint error, I have been
>> stuck on for quite a while.
>>
>> Basically I am adding support for Int32# on top of the In8#(D4475) and
>> Int16#(D5006) patches.
>>
>> The Cmm being generated for the test programs are incorrect.
>>
>> Taking a sample test like this (
>> https://github.com/Abhiroop/ghc-1/blob/int8/testsuite/tests/ffi/should_run/PrimFFIInt32.hs
>> )
>>
>> The crux of the linting error is the type mismatch between LHS and RHS of
>> the CmmAssign statement.
>>
>> For example in the Int8 patch, the Cmm generated looks like this:
>>
>> ```
>> _s1MC::I8 = I8[Sp]; // CmmAssign
>> _s1MD::I8 = I8[Sp + 8]; // CmmAssign
>> _s1ME::I8 = I8[Sp + 16]; // CmmAssign
>> _s1MF::I8 = I8[Sp + 24]; // CmmAssign
>> _s1MG::I8 = I8[Sp + 32]; // CmmAssign
>> _s1MH::I8 = I8[Sp + 40]; // CmmAssign
>> _s1MI::I8 = I8[Sp + 48]; // CmmAssign
>> _s1MJ::I8 = I8[Sp + 56]; // CmmAssign
>> _s1MK::I8 = I8[Sp + 64]; // CmmAssign
>> _s1ML::I8 = I8[Sp + 72]; // CmmAssign
>> R6 = %MO_XX_Conv_W8_W64(_s1MG::I8); // CmmAssign
>> R5 = %MO_XX_Conv_W8_W64(_s1MF::I8); // CmmAssign
>> R4 = %MO_XX_Conv_W8_W64(_s1ME::I8); // CmmAssign
>> R3 = %MO_XX_Conv_W8_W64(_s1MD::I8); // CmmAssign
>> R2 = %MO_XX_Conv_W8_W64(_s1MC::I8); // CmmAssign
>> ```
>>
>> or
>>
>> ```
>> _c1Oq::I8 = %MO_SS_Conv_W64_W8(9); // CmmAssign
>> _s1N0::I8 = _c1Oq::I8; // CmmAssign
>> _c1Ou::I8 = %MO_SS_Conv_W64_W8(8); // CmmAssign
>> _s1MZ::I8 = _c1Ou::I8; // CmmAssign
>> _c1Ox::I8 = %MO_SS_Conv_W64_W8(7); // CmmAssign
>> _s1MY::I8 = _c1Ox::I8; // CmmAssign
>> _c1OA::I8 = %MO_SS_Conv_W64_W8(6); // CmmAssign
>> _s1MX::I8 = _c1OA::I8; // CmmAssign
>> _c1OD::I8 = %MO_SS_Conv_W64_W8(5); // CmmAssign
>> _s1MW::I8 = _c1OD::I8; // CmmAssign
>> _c1OG::I8 = %MO_SS_Conv_W64_W8(4); // CmmAssign
>> _s1MV::I8 = _c1OG::I8; // CmmAssign
>> _c1OJ::I8 = %MO_SS_Conv_W64_W8(3); // CmmAssign
>> _s1MU::I8 = _c1OJ::I8; // CmmAssign
>> ```
>>
>> Basically the registers on the left hand side have type `I8`, whereas in
>> my case the registers on the LHS always have the width equal to the word
>> size:
>>
>> ```
>> _c1Ok::I64 = %MO_SS_Conv_W64_W32(9); // CmmAssign
>> _s1N0::I64 = _c1Ok::I64; // CmmAssign
>> _c1Oo::I64 = %MO_SS_Conv_W64_W32(8); // CmmAssign
>> _s1MZ::I64 = _c1Oo::I64; // CmmAssign
>> _c1Or::I64 = %MO_SS_Conv_W64_W32(7); // CmmAssign
>> _s1MY::I64 = _c1Or::I64; // CmmAssign
>> _c1Ou::I64 = %MO_SS_Conv_W64_W32(6); // CmmAssign
>> _s1MX::I64 = _c1Ou::I64; // CmmAssign
>> _c1Ox::I64 = %MO_SS_Conv_W64_W32(5); // CmmAssign
>> _s1MW::I64 = _c1Ox::I64; // CmmAssign
>> _c1OA::I64 = %MO_SS_Conv_W64_W32(4); // CmmAssign
>> _s1MV::I64 = _c1OA::I64; // CmmAssign
>> _c1OD::I64 = %MO_SS_Conv_W64_W32(3); // CmmAssign
>> _s1MU::I64 = _c1OD::I64; // CmmAssign
>> _c1OG::I64 = %MO_SS_Conv_W64_W32(2); // CmmAssign
>> _s1MT::I64 = _c1OG::I64; // CmmAssign
>> ```
>> I would ideally want to have the datatype of the LHS be `I32`.
>>
>> Michal, I thought this type is picked up using the `primRepCmmType`
>> function
>> https://github.com/Abhiroop/ghc-1/blob/int8/compiler/cmm/CmmUtils.hs#L104-L105 which
>> I modified but I am not sure why the LHS types of the CmmAssign statement
>> allocate `I64` instead of `I32`. Is there any other change on your
>> patch(D4475) which I might have overlooked.
>>
>> I have uploaded my Int32# patch on phab as well for reference(
>> https://phabricator.haskell.org/D5032)
>>
>> Thanks,
>> Abhiroop
>>
>>
>>
>> On Wed, Aug 1, 2018 at 3:45 PM Michal Terepeta <michal.terepeta at gmail.com>
>> wrote:
>>
>>> 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!
>>>>>>
>>>>>
>>
>> --
>> Kloona - Coming Soon!
>>
>
>
> --
> Kloona - Coming Soon!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180801/b48605a7/attachment-0001.html>
More information about the ghc-devs
mailing list