August 2018 - ghc-devs

accuracy of asinh and atanh
by Matt Peddie 03 Aug '18

03 Aug '18

Hi devs, I tried to use asinh :: Double -> Double and discovered that it's inaccurate compared to my system library (GNU libm), even returning -Infinity in place of finite values in the neighborhood of -22 for large negative arguments. `atanh` is also inaccurate compared to the system library. I wrote up a more detailed description of the problem including plots in the README file at https://github.com/peddie/ghc-inverse-hyperbolic -- this repository is package that can help you examine the error for yourself or generate the plots, and it also contains accurate pure-Haskell translations of the system library's implementation for these functions. What's the next step to fixing this in GHC? Cheers Matt Peddie

7 11

understanding assertions, part deux :) Re: whither built in unlifted Word32# / Word64# etc?
by Carter Schonwald 02 Aug '18

02 Aug '18

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#… 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#… 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(a)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/Pri…) > 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#… > > 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(a)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(a)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(a)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&whitespa…) >>>> 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(a)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(a)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:W…> >>>>> -> Word64X2# >>>>> <https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:W…> which >>>>> should rather be broadcastWord64X2# :: Word64# >>>>> <https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:W…> >>>>> -> Word64X2# >>>>> <https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html#t:W…> >>>>> >>>>> 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-3339515… >>>>> >>>>> Thanks, >>>>> Abhiroop >>>>> >>>>> On Mon, May 28, 2018 at 6:06 PM, Michal Terepeta < >>>>> michal.terepeta(a)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(a)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! >

3 7

Re: [Haskell-cafe] Access violation when stack haddock haskell-src-exts since LTS 12.0
by Sven Panne 02 Aug '18

02 Aug '18

Am Mo., 23. Juli 2018 um 05:49 Uhr schrieb Yuji Yamamoto < whosekiteneverfly(a)gmail.com>: > Thank you very much! > > I confirmed the replaced haddock executable can successfully generate the > docs! > Yesterday I had quite some trouble because of the Haddock problem, too, and I guess I'm not alone: haskell-src-exts has 165 direct reverse dependencies, so probably hundreds of Hackage packages are affected by this. The workaround is simple (don't use --haddock with stack), but far from satisfying and not very obvious. Given the fact that this affects a very central piece of the Haskell infrastructure in its latest stable incarnation (GHC 8.4.3): Can we have an 8.4.4 with a fixed Haddock?

3 2

Failure to Build
by Ara Adkins 01 Aug '18

01 Aug '18

Hey Devs, I'm having trouble building the head of the ghc-8.6 branch (`26a7f850d1`) on my Arch Linux machine. The essence of the error is this as follows, though the full result of make (to the point of error) is attached. ``` Configuring template-haskell-2.14.0.0... ghc-cabal: Encountered missing dependencies: ghc-boot-th ==8.6.* && ==8.7 ``` The output of configure is as follows: ``` ---------------------------------------------------------------------- Configure completed successfully. Building GHC version : 8.7.20180730 Git commit id : 26a7f850d15b91ad68d1e28d467faba00bb79144 Build platform : x86_64-unknown-linux Host platform : x86_64-unknown-linux Target platform : x86_64-unknown-linux Bootstrapping using : /usr/bin/ghc which is version : 8.4.3 Using (for bootstrapping) : gcc Using gcc : gcc which is version : 8.1.1 Building a cross compiler : NO Unregisterised : NO hs-cpp : gcc hs-cpp-flags : -E -undef -traditional ar : ar ld : ld.gold nm : nm libtool : libtool objdump : objdump ranlib : ranlib windres : dllwrap : genlib : Happy : /home/ara/.local/bin/happy (1.19.9) Alex : /usr/bin/alex (3.2.4) Perl : /usr/bin/perl sphinx-build : /usr/bin/sphinx-build xelatex : /usr/bin/xelatex Using LLVM tools clang : clang llc : opt : HsColour : /usr/bin/HsColour Tools to build Sphinx HTML documentation available: YES Tools to build Sphinx PDF documentation available: YES ---------------------------------------------------------------------- ``` Any help would be most appreciated. Best, _ara

4 6

RE: [commit: ghc] master: Revert "Don't inline functions with RULES too early" (1df50a0)
by Simon Peyton Jones 01 Aug '18

01 Aug '18

Bother. Sorry, I did validate, but maybe not clean enough... | -----Original Message----- | From: ghc-commits <ghc-commits-bounces(a)haskell.org> On Behalf Of | git(a)git.haskell.org | Sent: 01 August 2018 11:55 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Revert "Don't inline functions with RULES too | early" (1df50a0) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haskell. | org%2Ftrac%2Fghc%2Fchangeset%2F1df50a0f61f320428f2e6dd07b3c9ce49c4acd31%2Fgh | c&data=02%7C01%7Csimonpj%40microsoft.com%7Cf0f94d0215cc45d3c05f08d5f79d3 | bcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636687177045114421&sdat | a=KJfA0OCKfpsAKB0Zz8Z%2FS9mnqr3D3gLhn6AYd7ddzE4%3D&reserved=0 | | >--------------------------------------------------------------- | | commit 1df50a0f61f320428f2e6dd07b3c9ce49c4acd31 | Author: Ben Gamari <ben(a)smart-cactus.org> | Date: Wed Aug 1 06:42:19 2018 -0400 | | Revert "Don't inline functions with RULES too early" | | This commit causes significant performance regressions: | ``` | bytes allocated value is too high: | Expected T9872d(normal) bytes allocated: 578498120 +/-5% | Lower bound T9872d(normal) bytes allocated: 549573214 | Upper bound T9872d(normal) bytes allocated: 607423026 | Actual T9872d(normal) bytes allocated: 677179968 | Deviation T9872d(normal) bytes allocated: 17.1 % | bytes allocated value is too high: | Expected T9872c(normal) bytes allocated: 3096670112 +/-5% | Lower bound T9872c(normal) bytes allocated: 2941836606 | Upper bound T9872c(normal) bytes allocated: 3251503618 | Actual T9872c(normal) bytes allocated: 3601872536 | Deviation T9872c(normal) bytes allocated: 16.3 % | bytes allocated value is too high: | Expected T9872b(normal) bytes allocated: 3730686224 +/-5% | Lower bound T9872b(normal) bytes allocated: 3544151912 | Upper bound T9872b(normal) bytes allocated: 3917220536 | Actual T9872b(normal) bytes allocated: 4374298272 | Deviation T9872b(normal) bytes allocated: 17.3 % | bytes allocated value is too high: | Expected T9872a(normal) bytes allocated: 2729927408 +/-5% | Lower bound T9872a(normal) bytes allocated: 2593431037 | Upper bound T9872a(normal) bytes allocated: 2866423779 | Actual T9872a(normal) bytes allocated: 3225788896 | Deviation T9872a(normal) bytes allocated: 18.2 % | ``` | It's not clear that this was intentional so I'm going to revert for now. | | This reverts commit 2110738b280543698407924a16ac92b6d804dc36. | | | >--------------------------------------------------------------- | | 1df50a0f61f320428f2e6dd07b3c9ce49c4acd31 | compiler/basicTypes/BasicTypes.hs | 10 ----- | compiler/basicTypes/MkId.hs | 2 +- | compiler/specialise/Rules.hs | 49 ++++--------------- | --- | compiler/stranal/WorkWrap.hs | 4 +- | testsuite/tests/simplCore/should_compile/T15445.hs | 8 ---- | .../tests/simplCore/should_compile/T15445.stderr | 13 ------ | .../tests/simplCore/should_compile/T15445a.hs | 10 ----- | testsuite/tests/simplCore/should_compile/all.T | 1 - | 8 files changed, 10 insertions(+), 87 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies-harder - | -ignore-space-at-eol --cc 1df50a0f61f320428f2e6dd07b3c9ce49c4acd31 | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell | .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7Cf0f94d0215cc45d3c05f08d | 5f79d3bcf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636687177045114421&am | p;sdata=7D%2F6r1pP1Pizyev6tFZzHW9pJEsRxwd1r7AnX44KSdc%3D&reserved=0

1 0