<div dir="ltr">Never mind I found the issue and fixed it. <div><br></div><div>It was the definition of the `Int32` type constructor:</div><div><br></div><div>int32PrimTyCon = pcPrimTyCon0 int32PrimTyConName IntRep<br></div><div><br></div><div>which had to be fixed to</div><div><br></div><div>int32PrimTyCon = pcPrimTyCon0 int32PrimTyConName Int32Rep<br></div><div><br></div><div>Thanks anyways :)</div><div><br></div><div>Abhiroop</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 1, 2018 at 5:36 PM Abhiroop Sarkar <<a href="mailto:asiamgenius@gmail.com">asiamgenius@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>I would appreciate some help in debugging a Cmm Lint error, I have been stuck on for quite a while.<br><br>Basically I am adding support for Int32# on top of the In8#(D4475) and Int16#(D5006) patches.</div><div><br></div><div>The Cmm being generated for the test programs are incorrect.</div><div><br></div><div>Taking a sample test like this (<a href="https://github.com/Abhiroop/ghc-1/blob/int8/testsuite/tests/ffi/should_run/PrimFFIInt32.hs" target="_blank">https://github.com/Abhiroop/ghc-1/blob/int8/testsuite/tests/ffi/should_run/PrimFFIInt32.hs</a>)</div><div><br></div><div>The crux of the linting error is the type mismatch between LHS and RHS of the CmmAssign statement.</div><div><br></div><div>For example in the Int8 patch, the Cmm generated looks like this:</div><div><br></div><div>```<br><div> _s1MC::I8 = I8[Sp]; // CmmAssign</div><div> _s1MD::I8 = I8[Sp + 8]; // CmmAssign</div><div> _s1ME::I8 = I8[Sp + 16]; // CmmAssign</div><div> _s1MF::I8 = I8[Sp + 24]; // CmmAssign</div><div> _s1MG::I8 = I8[Sp + 32]; // CmmAssign</div><div> _s1MH::I8 = I8[Sp + 40]; // CmmAssign</div><div> _s1MI::I8 = I8[Sp + 48]; // CmmAssign</div><div> _s1MJ::I8 = I8[Sp + 56]; // CmmAssign</div><div> _s1MK::I8 = I8[Sp + 64]; // CmmAssign</div><div> _s1ML::I8 = I8[Sp + 72]; // CmmAssign</div><div> R6 = %MO_XX_Conv_W8_W64(_s1MG::I8); // CmmAssign</div><div> R5 = %MO_XX_Conv_W8_W64(_s1MF::I8); // CmmAssign</div><div> R4 = %MO_XX_Conv_W8_W64(_s1ME::I8); // CmmAssign</div><div> R3 = %MO_XX_Conv_W8_W64(_s1MD::I8); // CmmAssign</div><div> R2 = %MO_XX_Conv_W8_W64(_s1MC::I8); // CmmAssign<br></div>```</div><div><br></div><div>or </div><div><br></div><div>```<br><div> _c1Oq::I8 = %MO_SS_Conv_W64_W8(9); // CmmAssign</div><div> _s1N0::I8 = _c1Oq::I8; // CmmAssign</div><div> _c1Ou::I8 = %MO_SS_Conv_W64_W8(8); // CmmAssign</div><div> _s1MZ::I8 = _c1Ou::I8; // CmmAssign</div><div> _c1Ox::I8 = %MO_SS_Conv_W64_W8(7); // CmmAssign</div><div> _s1MY::I8 = _c1Ox::I8; // CmmAssign</div><div> _c1OA::I8 = %MO_SS_Conv_W64_W8(6); // CmmAssign</div><div> _s1MX::I8 = _c1OA::I8; // CmmAssign</div><div> _c1OD::I8 = %MO_SS_Conv_W64_W8(5); // CmmAssign</div><div> _s1MW::I8 = _c1OD::I8; // CmmAssign</div><div> _c1OG::I8 = %MO_SS_Conv_W64_W8(4); // CmmAssign</div><div> _s1MV::I8 = _c1OG::I8; // CmmAssign</div><div> _c1OJ::I8 = %MO_SS_Conv_W64_W8(3); // CmmAssign</div><div> _s1MU::I8 = _c1OJ::I8; // CmmAssign</div>```</div><div><br></div><div>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:</div><div><br></div><div>```<br><div> _c1Ok::I64 = %MO_SS_Conv_W64_W32(9); // CmmAssign</div><div> _s1N0::I64 = _c1Ok::I64; // CmmAssign</div><div> _c1Oo::I64 = %MO_SS_Conv_W64_W32(8); // CmmAssign</div><div> _s1MZ::I64 = _c1Oo::I64; // CmmAssign</div><div> _c1Or::I64 = %MO_SS_Conv_W64_W32(7); // CmmAssign</div><div> _s1MY::I64 = _c1Or::I64; // CmmAssign</div><div> _c1Ou::I64 = %MO_SS_Conv_W64_W32(6); // CmmAssign</div><div> _s1MX::I64 = _c1Ou::I64; // CmmAssign</div><div> _c1Ox::I64 = %MO_SS_Conv_W64_W32(5); // CmmAssign</div><div> _s1MW::I64 = _c1Ox::I64; // CmmAssign</div><div> _c1OA::I64 = %MO_SS_Conv_W64_W32(4); // CmmAssign</div><div> _s1MV::I64 = _c1OA::I64; // CmmAssign</div><div> _c1OD::I64 = %MO_SS_Conv_W64_W32(3); // CmmAssign</div><div> _s1MU::I64 = _c1OD::I64; // CmmAssign</div><div> _c1OG::I64 = %MO_SS_Conv_W64_W32(2); // CmmAssign</div><div> _s1MT::I64 = _c1OG::I64; // CmmAssign</div>```<br>I would ideally want to have the datatype of the LHS be `I32`.<br><br>Michal, I thought this type is picked up using the `primRepCmmType` function <a href="https://github.com/Abhiroop/ghc-1/blob/int8/compiler/cmm/CmmUtils.hs#L104-L105" target="_blank">https://github.com/Abhiroop/ghc-1/blob/int8/compiler/cmm/CmmUtils.hs#L104-L105</a> 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.</div><div><br></div><div>I have uploaded my Int32# patch on phab as well for reference(<a href="https://phabricator.haskell.org/D5032" target="_blank">https://phabricator.haskell.org/D5032</a>)<br><br>Thanks,</div><div>Abhiroop<br> </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 1, 2018 at 3:45 PM Michal Terepeta <<a href="mailto:michal.terepeta@gmail.com" target="_blank">michal.terepeta@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I've rebased the diff and relaxed the assertion - do take a look if that looks reasonable to you :)<div><a href="https://phabricator.haskell.org/D4475" target="_blank">https://phabricator.haskell.org/D4475</a><br><div><br></div><div>Cheers!</div><div><br></div><div>- Michal</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 25, 2018 at 9:03 PM Michal Terepeta <<a href="mailto:michal.terepeta@gmail.com" target="_blank">michal.terepeta@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Carter,</div><div><br></div>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).<div><br></div><div>I'll try to have a look at it this weekend.</div><div><br></div><div>Cheers!</div></div><div dir="ltr"><div><br></div><div>- Michal</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 25, 2018 at 2:16 AM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Michal: did you write this Assert about width? and if so could you explain it so we can understand?</div><div><br></div>hrmm... that code is in the procedure for generating C calls for 64bit intel systems<div><a href="https://github.com/michalt/ghc/blob/int8/compiler/nativeGen/X86/CodeGen.hs#L2541" target="_blank">https://github.com/michalt/ghc/blob/int8/compiler/nativeGen/X86/CodeGen.hs#L2541</a> is the top of that routine<br></div><div><br></div><div>and width is defined right below the spot in question</div><div><a href="https://github.com/michalt/ghc/blob/int8/compiler/nativeGen/X86/CodeGen.hs#L2764-L2774" target="_blank">https://github.com/michalt/ghc/blob/int8/compiler/nativeGen/X86/CodeGen.hs#L2764-L2774</a><br></div><div><br></div><div>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?)</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 23, 2018 at 8:54 PM Abhiroop Sarkar <<a href="mailto:asiamgenius@gmail.com" target="_blank">asiamgenius@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Michal,<div><br></div><div>In the tests that you have added to D4475, are all the tests running fine?</div><div><br></div><div>On my machine, I was running the FFI tests(<a href="https://github.com/michalt/ghc/blob/int8/testsuite/tests/ffi/should_run/PrimFFIInt8.hs" target="_blank">https://github.com/michalt/ghc/blob/int8/testsuite/tests/ffi/should_run/PrimFFIInt8.hs</a>) and they seem to fail at a particular assert statement in the code generator.</div><div><br></div><div>To be precise this one: <a href="https://github.com/michalt/ghc/blob/int8/compiler/nativeGen/X86/CodeGen.hs#L2764" target="_blank">https://github.com/michalt/ghc/blob/int8/compiler/nativeGen/X86/CodeGen.hs#L2764</a></div><div><br></div><div>Upon commenting that assert the tests run fine. Am I missing something or is the failure expected?</div><div><br></div><div>Thanks,</div><div>Abhiroop</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jul 9, 2018 at 8:31 PM Michal Terepeta <<a href="mailto:michal.terepeta@gmail.com" target="_blank">michal.terepeta@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Just for the record, I've uploaded the changes to binary:<div><a href="https://github.com/michalt/packages-binary/tree/int8" target="_blank">https://github.com/michalt/packages-binary/tree/int8</a><br></div><div><br></div><div>- Michal</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 4, 2018 at 11:07 AM Michal Terepeta <<a href="mailto:michal.terepeta@gmail.com" target="_blank">michal.terepeta@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Yeah, if you look at the linked diff, there are a few tiny changes to binary that are necessary.<div><br></div><div>I'll try to upload them to github later this week.</div><div><br></div><div>Ben, is something blocking the review of the diff? I think I addressed all comments so far.</div></div><div dir="ltr"><div><br></div><div>- Michal</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 4, 2018 at 1:38 AM Abhiroop Sarkar <<a href="mailto:asiamgenius@gmail.com" target="_blank">asiamgenius@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello Michal,<div><br></div><div>I was looking at your diff <a href="https://phabricator.haskell.org/D4475" style="color:rgb(17,85,204);background-color:rgb(255,255,255)" target="_blank">https://phabricator.haskell.org/D4475</a><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> and there seems to be some changes that you perhaps made in the binary package (</span></span><a href="https://phabricator.haskell.org/differential/changeset/?ref=199152&whitespace=ignore-most" target="_blank">https://phabricator.haskell.org/differential/changeset/?ref=199152&whitespace=ignore-most</a>). 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?</div><div><br></div><div>Thanks</div></div><div dir="ltr"><div><br>Abhiroop</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, May 28, 2018 at 10:45 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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. <div><br></div><div><br><br><div id="m_2599288537554081330m_-7928647434561846528m_5924623889990065071m_-8239688094280744484m_603572655493312715gmail-m_-5747724948256703237m_-4312343456857310231m_-5382419903540304595m_-1975785906934280214m_829261999365360526AppleMailSignature">-Carter</div><div><br>On May 28, 2018, at 5:02 PM, Abhiroop Sarkar <<a href="mailto:asiamgenius@gmail.com" target="_blank">asiamgenius@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hello Michal,<div><br></div><div>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.</div><div><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">> Out of curiosity, why do you need Word64#/Word32# story to be fixed for SIMD?</span><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="font-size:12.8px">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. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">One more example is this vector operation like : <a id="m_2599288537554081330m_-7928647434561846528m_5924623889990065071m_-8239688094280744484m_603572655493312715gmail-m_-5747724948256703237m_-4312343456857310231m_-5382419903540304595m_-1975785906934280214m_829261999365360526gmail-v:broadcastWord64X2-35-" class="m_2599288537554081330m_-7928647434561846528m_5924623889990065071m_-8239688094280744484m_603572655493312715gmail-m_-5747724948256703237m_-4312343456857310231m_-5382419903540304595m_-1975785906934280214m_829261999365360526gmail-def" style="margin:0px;padding:0px;text-decoration:none;font-weight:bold;color:rgb(0,0,0);font-family:monospace;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">broadcastWord64X2#</a><span style="color:rgb(0,0,0);font-family:monospace;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(240,240,240);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>::<span> </span></span><a href="https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:Word-35-" title="GHC.Prim" style="margin:0px;padding:0px;text-decoration:none;color:rgb(171,105,84);font-family:monospace;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">Word#</a><span style="color:rgb(0,0,0);font-family:monospace;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(240,240,240);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>-><span> </span></span><a href="https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:Word64X2-35-" title="GHC.Prim" style="margin:0px;padding:0px;text-decoration:none;color:rgb(171,105,84);font-family:monospace;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">Word64X2#</a> which should rather be <a id="m_2599288537554081330m_-7928647434561846528m_5924623889990065071m_-8239688094280744484m_603572655493312715gmail-m_-5747724948256703237m_-4312343456857310231m_-5382419903540304595m_-1975785906934280214m_829261999365360526gmail-v:broadcastWord64X2-35-" class="m_2599288537554081330m_-7928647434561846528m_5924623889990065071m_-8239688094280744484m_603572655493312715gmail-m_-5747724948256703237m_-4312343456857310231m_-5382419903540304595m_-1975785906934280214m_829261999365360526gmail-def" style="margin:0px;padding:0px;text-decoration:none;font-weight:bold;color:rgb(0,0,0);font-family:monospace;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">broadcastWord64X2#</a><span style="color:rgb(0,0,0);font-family:monospace;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(240,240,240);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>::<span> </span></span><a href="https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:Word-35-" title="GHC.Prim" style="margin:0px;padding:0px;text-decoration:none;color:rgb(171,105,84);font-family:monospace;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">Word64#</a><span style="color:rgb(0,0,0);font-family:monospace;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(240,240,240);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>-><span> </span></span><a href="https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:Word64X2-35-" title="GHC.Prim" style="margin:0px;padding:0px;text-decoration:none;color:rgb(171,105,84);font-family:monospace;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">Word64X2#</a></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Another reason could be improving the space efficiency of packing various datatypes. This was explained in some detail in this comment: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/74#issuecomment-333951559" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/74#issuecomment-333951559</a></span></div><div><br></div><div>Thanks,</div><div>Abhiroop</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 28, 2018 at 6:06 PM, Michal Terepeta <span dir="ltr"><<a href="mailto:michal.terepeta@gmail.com" target="_blank">michal.terepeta@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Hey Carter,</div><div><br></div><div>Yeah, I'm totally snowed under with personal stuff at the moment, so not much time to hack on</div><div>anything. I've managed to make some progress on <a href="https://phabricator.haskell.org/D4475" target="_blank">https://phabricator.haskell.org/D4475</a> (prototype</div><div>that adds Int8#/Word8#; waiting for another round of review). Sadly June still looks a bit crazy for</div><div>me, so I can't promise anything for Word64#/Word32# (and Int64#/Int32#). I hope to have some more</div><div>time in July.</div><div><br></div><div>If this is blocking you, then please don't wait for me and go ahead (my diff for Int8#/Word8# might</div><div>be a decent starting point to see which places might need changes).</div><div><br></div><div>Out of curiosity, why do you need Word64#/Word32# story to be fixed for SIMD? Cmm already has</div><div>separate types for vector types (see TyCon.hs and VecRep constructor of PrimRep).</div><div><br></div><div>Cheers!</div><span class="m_2599288537554081330m_-7928647434561846528m_5924623889990065071m_-8239688094280744484m_603572655493312715gmail-m_-5747724948256703237m_-4312343456857310231m_-5382419903540304595m_-1975785906934280214m_829261999365360526HOEnZb"><font color="#888888"><div><br></div><div>- Michal</div></font></span><div><br></div><div>PS. Are you coming to ZuriHac by any chance?</div></div></div><div class="m_2599288537554081330m_-7928647434561846528m_5924623889990065071m_-8239688094280744484m_603572655493312715gmail-m_-5747724948256703237m_-4312343456857310231m_-5382419903540304595m_-1975785906934280214m_829261999365360526HOEnZb"><div class="m_2599288537554081330m_-7928647434561846528m_5924623889990065071m_-8239688094280744484m_603572655493312715gmail-m_-5747724948256703237m_-4312343456857310231m_-5382419903540304595m_-1975785906934280214m_829261999365360526h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, May 28, 2018 at 12:37 AM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hey Michal!<div>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.</div><div><br></div><div>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 </div></div><div dir="ltr"><div><br></div><div>-Carter</div></div>
</blockquote></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_2599288537554081330m_-7928647434561846528m_5924623889990065071m_-8239688094280744484m_603572655493312715gmail-m_-5747724948256703237m_-4312343456857310231m_-5382419903540304595m_-1975785906934280214m_829261999365360526gmail_signature"><div dir="ltr">Kloona - Coming Soon!<br></div></div>
</div>
</div></blockquote></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_2599288537554081330m_-7928647434561846528m_5924623889990065071m_-8239688094280744484m_603572655493312715gmail-m_-5747724948256703237m_-4312343456857310231m_-5382419903540304595m_-1975785906934280214gmail_signature"><div dir="ltr">Kloona - Coming Soon!<br></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_2599288537554081330m_-7928647434561846528m_5924623889990065071m_-8239688094280744484m_603572655493312715gmail-m_-5747724948256703237gmail_signature"><div dir="ltr">Kloona - Coming Soon!<br></div></div>
</blockquote></div></div></blockquote></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_2599288537554081330m_-7928647434561846528gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Kloona - Coming Soon!<br></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Kloona - Coming Soon!<br></div></div>