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

[Michal Terepeta]

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 
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 
> 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 
>> 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 
 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=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 
>> 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#
>> 
>>  -> Word64X2#
>> 

RE: [Diffusion] [Committed] rGHCDIFFe79e580be5d3: Fix Trac #5117: desugar literal patterns consistencly

[Ben Gamari]

Simon Peyton Jones via ghc-devs  writes:

> Is anyone else getting messages like the one below?
>
> I have received over 1,000 of them this morning. It is tiresome.
>
I have also received a few. I'm looking into it.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Steps to propose a new primop in GHC

[Mitsutoshi Aoe]

Hi Ben,

I just submitted a patch (with slightly different names from the earlier
message) for this change at h 
ttps://phabricator.haskell.org/D5007 .
This is my first time using the Phab so please let me know if I'm doing
something wrong.

Best,
Mitsutoshi

2018年5月30日(水) 10:36 Ben Gamari :

> Mitsutoshi Aoe  writes:
>
> > Hi Ben,
> >
> > Thanks for your reply. I take that at least for the GHC part I can
> > submit the diff to phab and ask for review. I’ll do it.
> >
> Absolutely. I'm looking forward to seeing it.
>
> >> As far as adding a wrapper in `base`, I think we can just go ahead and
> > do it.
> >
> > Note that the wrapper cannot live in base doe to the dependency on
> > bytestring. I’m thinking to put it in my ghc-trace-events for now.
> >
> Yes, of course. Silly me.
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs