ghci recompilation avoidance
After switching to git, I discovered that ghci is interpreting a lot of modules when it should have loaded the .o files (i.e. I get 'SomeModule (interpreted)' instead of 'Skipped SomeModule'). It turns out that git checkouts update the modtime on checked-out files, even when they get reverted back to their original contents. Shake has an option ChangeModtimeAndDigestInput to check file contents in addition to modtime to not get fooled by this, but ghc is still doing a plain modtime check. So shake correctly skips the rebuild on those modules, but ghci recompiles them anyway. This means I'm better off just disabling shake's digest check, since otherwise I can just never recompile that stuff at all. Would it be reasonable to do the same kind of check as shake in ghc? Namely, shake does a quick check if modtime has changed, but even if it has, it checks the file contents digest to make sure. My understanding is that ghc does the quick modtime check, and then does an expensive interface check. This would augment that to become a quick modtime check, then a quick-ish digest check, and then the expensive interface check. I guess the old input file digest will have to be stored somewhere, presumably in the .hi file, so it's not a totally trivial change. The benefit should be that anyone working with git should be able to reuse more .o files after branch checkouts. The two relevant places seem to be GHC.loadModule and DriverPipeline.runPhase. I'm willing to have a go at this if people think it's a good idea and I can get some pointers on the .hi plumbing if I get hung up there. ___ 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 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 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
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. > 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. Regards, Mitsutoshi 2018年5月30日 5:33 +0900、Ben Gamari のメール: > Mitsutoshi Aoe writes: > > > Hi devs, > > > > I'm thinking to add a primop in GHC but not sure how I should proceed. The > > primop I have in mind is something like: > > > > traceEventBinary# :: Addr# -> Int# -> State# s -> State# s > > > > This function is similar to the existing traceEvent# but it takes a chunk > > of bytes rather than a null-terminated string. It is useful to trace custom > > user events (e.g. network packet arrival timestamps in an network > > application) in eventlogs. At library level, it is supposed to be used like > > the tracing functions in Debug.Trace but with ByteString argument: > > > > traceEventBinary :: ByteString -> a -> a > > traceEventBinaryIO :: ByteString -> IO () > > > > Note that this can't live in base because of the dependency on bytestring. > > > > So how should I proceed from here? Am I supposed to submit a GHC proposal > > or should I ask on the libraries list? This is not a prominently visible > > change in GHC. It rather affects only ghc-prim and no effects in base. > > > Hmm, that is a good question. I have also needed something like your > traceEventBinary# in the past and I think adding the primop is rather > non-controversial. > > As far as adding a wrapper in `base`, I think we can just go ahead and > do it. `Debug.Trace` module isn't defined by the Haskell Report so I > don't think there's a need to involve the CLC here. > > Cheers, > > - Ben > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: -ddump-simpl-phases
Gabor Greif writes: > Hi all, > > the manual mentions `-ddump-simpl-phases` but there is no such flag > [1]. How should we fix this? > How does D4750 look to you? 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 writes: > Hi devs, > > I'm thinking to add a primop in GHC but not sure how I should proceed. The > primop I have in mind is something like: > > traceEventBinary# :: Addr# -> Int# -> State# s -> State# s > > This function is similar to the existing traceEvent# but it takes a chunk > of bytes rather than a null-terminated string. It is useful to trace custom > user events (e.g. network packet arrival timestamps in an network > application) in eventlogs. At library level, it is supposed to be used like > the tracing functions in Debug.Trace but with ByteString argument: > > traceEventBinary :: ByteString -> a -> a > traceEventBinaryIO :: ByteString -> IO () > > Note that this can't live in base because of the dependency on bytestring. > > So how should I proceed from here? Am I supposed to submit a GHC proposal > or should I ask on the libraries list? This is not a prominently visible > change in GHC. It rather affects only ghc-prim and no effects in base. > Hmm, that is a good question. I have also needed something like your traceEventBinary# in the past and I think adding the primop is rather non-controversial. As far as adding a wrapper in `base`, I think we can just go ahead and do it. `Debug.Trace` module isn't defined by the Haskell Report so I don't think there's a need to involve the CLC here. 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
[ANNOUNCE] GHC 8.4.3 released
Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.3. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.3 This release includes a few bug fixes including: * A code generation bug resulting in crashing of some programs using UnboxedSums has been fixed (#15038). * #14381, where Cabal and GHC would disagree about abi-depends, resulting in build failures, has been worked around. Note that the work-around patch has already been shipped by several distributions in previous releases, so this change may not be visible to you. * By popular demand, GHC now logs a message when it reads a package environment file, hopefully eliminating some of the confusion wrought by this feature. * GHC now emits assembler agreeable to newer versions of Gnu binutils, fixing #15068. * SmallArray#s can now be compacted into a compact region Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standardized lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~ Relevant URLs: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/TeamGHC Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site: https://ghc.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Many GHC developers hang out on #haskell on IRC: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
LclId -> GblId question
Hi devs,
I have a simple question, but could not find an answer yet. The same
variable (I checked!) appears in two dumps with different names and
different external visibilities.
Which pass transforms this variable to a global id, and why? Shouldn't
a LclId remain local along the entire optimisation chain?
Any hint appreciated!
Cheers and thanks,
Gabor
Snippets from dumps below
##
-rw-r--r-- 1 ggreif sw12 3281225 May 29 14:14 TcSMonad.dump-stranal
-- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0}
lvl_sOra :: TcTyVarDetails
[LclId,
Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False,
WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}]
lvl_sOra
= ghc-prim-0.5.3:GHC.Magic.noinline
@ TcTyVarDetails vanillaSkolemTv
##
-rw-r--r-- 1 ggreif sw12 1438015 May 29 14:14 TcSMonad.dump-simpl
-- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0}
TcSMonad.isFilledMetaTyVar_maybe2 :: TcTyVarDetails
[GblId,
Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False,
WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}]
TcSMonad.isFilledMetaTyVar_maybe2
= ghc-prim-0.5.3:GHC.Magic.noinline
@ TcTyVarDetails vanillaSkolemTv
##
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-ddump-simpl-phases
Hi all, the manual mentions `-ddump-simpl-phases` but there is no such flag [1]. How should we fix this? Cheers, Gabor [1] $ git grep ddump-simpl-phases docs/users_guide/debugging.rst:outputs even more information than ``-ddump-simpl-phases``. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Why do we prevent static archives from being loaded when DYNAMIC_GHC_PROGRAMS=YES?
Dear friends, when we build GHC with DYNAMIC_GHC_PROGRAMS=YES, we essentially prevent ghc/ghci from using archives (.a). Is there a technical reason behind this? The only only reasoning so far I've came across was: insist on using dynamic/shared objects, because the user said so when building GHC. In that case, we don't however prevent GHC from building archive (static) only libraries. And as a consequence when we later try to build another archive of a different library, that depends via TH on the former library, GHC will bail and complain that we don't have the relevant dynamic/shared object. Of course we don't we explicitly didn't build it. But the linker code we have in GHC is perfectly capable of loading archives. So why don't we want to fall back to archives? Similarly, as @deech asked on twitter[1], why we prevent GHCi from loading static libraries? I'd like to understand the technical reason/rational for this behavior. Can someone help me out here? If there is no fundamental reason for this behavior, I'd like to go ahead and try to lift it. Thank you! Cheers, Moritz --- [1]: https://twitter.com/deech/status/1001182709555908608 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ZuriHac 2018 GHC DevOps track - Request for Contributions
Hi Niklas, Sorry for slow reply - I'm totally snowed under at the moment. I should be able to give some overview/examples of what are primops and how they go through the compilation pipeline. And talk a bit about the Cmm-level parts of GHC. But I won't have much time to prepare, so there might be fair amount of improvisation... Are you coming to this week's HaskellerZ meetup? We could chat a bit more about this. Cheers! - Michal On Tue, May 22, 2018 at 12:07 PM Niklas Hambüchen wrote: > On 08/04/2018 15.01, Michal Terepeta wrote: > > I'd be happy to help. :) I know a bit about the backend (e.g., cmm > level), but it might be tricky to find there some smaller/self-contained > projects that would fit ZuriHac. > > Hey Michal, > > that's great. Is there a topic you would like to give a talk about, or a > pet peeve task that you'd like to tick off with the help of new potential > contributors in a hacking session? > > Other topics that might be nice and that you might know about are "How do > I add a new primop to GHC", handling all the way from the call on the > Haskell side to emitting the code, or (if I remember that correctly) > checking out that issue that GHC doesn't do certain optimisations yet (such > as emitting less-than-full-word instructions e.g. for adding two Word8s, or > lack of some strength reductions as in [1]). > > > You've mentioned performance regression tests - maybe we could also work > on improving nofib? > > For sure! > Shall we run a hacking session together where we let attendees work on > both performance regression tests and nofib? It seems these two fit well > together. > > Niklas > > [1]: > https://stackoverflow.com/questions/23315001/maximizing-haskell-loop-performance-with-ghc/23322255#23322255 > > > ___ 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
I forgot to mention that I have prototype implementation: * https://github.com/maoe/ghc/tree/traceEventBinary * https://github.com/maoe/ghc-trace-events/blob/feature/traceEventBinary/src/Debug/Trace/ByteString.hs#L46-L58 Some details still need to be sorted out though. Regards, Mitsutoshi 2018年5月28日(月) 16:23 Mitsutoshi Aoe : > Hi devs, > > I'm thinking to add a primop in GHC but not sure how I should proceed. The > primop I have in mind is something like: > > traceEventBinary# :: Addr# -> Int# -> State# s -> State# s > > This function is similar to the existing traceEvent# but it takes a chunk > of bytes rather than a null-terminated string. It is useful to trace custom > user events (e.g. network packet arrival timestamps in an network > application) in eventlogs. At library level, it is supposed to be used like > the tracing functions in Debug.Trace but with ByteString argument: > > traceEventBinary :: ByteString -> a -> a > traceEventBinaryIO :: ByteString -> IO () > > Note that this can't live in base because of the dependency on bytestring. > > So how should I proceed from here? Am I supposed to submit a GHC proposal > or should I ask on the libraries list? This is not a prominently visible > change in GHC. It rather affects only ghc-prim and no effects in base. > > Thanks, > Mitsutoshi > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Steps to propose a new primop in GHC
Hi devs, I'm thinking to add a primop in GHC but not sure how I should proceed. The primop I have in mind is something like: traceEventBinary# :: Addr# -> Int# -> State# s -> State# s This function is similar to the existing traceEvent# but it takes a chunk of bytes rather than a null-terminated string. It is useful to trace custom user events (e.g. network packet arrival timestamps in an network application) in eventlogs. At library level, it is supposed to be used like the tracing functions in Debug.Trace but with ByteString argument: traceEventBinary :: ByteString -> a -> a traceEventBinaryIO :: ByteString -> IO () Note that this can't live in base because of the dependency on bytestring. So how should I proceed from here? Am I supposed to submit a GHC proposal or should I ask on the libraries list? This is not a prominently visible change in GHC. It rather affects only ghc-prim and no effects in base. Thanks, Mitsutoshi ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Unable to build on NixOS
> For some more technical background, the "InfoTableProf" module is only > built/needed > when it is used with PROFILING. It uses CPP to "peek" into the StgInfoTable, > which changes under profiling. I think my issue was that nixpkgs.ghcHEAD configurePhase was overwriting my build.mk. That might explain why profiling was enabled. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Unable to build on NixOS
Huh,
So this is a bug I thought I dealt with :/
In the short term, I've found that often simply trying the build again can fix
it. This is a dependency issue that I don't 100% understand.
For some more technical background, the "InfoTableProf" module is only
built/needed when it is used with PROFILING. It uses CPP to "peek" into the
StgInfoTable, which changes under profiling.
My impression is that dependency resolution decides that module isn't
necessary, so then it is missing when it goes to use it. Again, I am not sure
here, that's just what seemed to be the issue.
Best,
Patrick Dougherty
On May 26, 2018, 8:39 PM -0500, Sean D Gillespie , wrote:
> Howdy,
>
> I am unable to build the latest revision of GHC on NixOS. I can build older
> revisions.
> Here's my error:
>
> ===--- building final phase
> make --no-print-directory -f ghc.mk phase=final all
> "inplace/bin/ghc-stage1" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof
> -eventlog -H32m -O -Wall -this-unit-id ghc-heap-8.5 -hide-all-packages -i
> -ilibraries/ghc-heap/. -ilibraries/gh
> c-heap/dist-install/build -Ilibraries/ghc-heap/dist-install/build
> -ilibraries/ghc-heap/dist-install/build/./autogen
> -Ilibraries/ghc-heap/dist-install/build/./autogen -Ilibraries/ghc-heap/.
> -optP-include
> -optPlibraries/ghc-heap/dist-install/build/./autogen/cabal_macros.h
> -package-id base-4.12.0.0 -package-id ghc-prim-0.5.3 -package-id rts -Wall
> -XHaskell2010 -O2 -no-user-packa
> ge-db -rtsopts -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir
> libraries/ghc-heap/dist-install/build -hidir
> libraries/ghc-heap/dist-install/build -stubdir libraries/ghc-heap/
> dist-install/build -split-sections -c
> libraries/ghc-heap/./GHC/Exts/Heap/Closures.hs -o
> libraries/ghc-heap/dist-install/build/GHC/Exts/Heap/Closures.p_o -dyno
> libraries/ghc-heap/dist-instal
> l/build/GHC/Exts/Heap/Closures.dyn_o
>
> libraries/ghc-heap/GHC/Exts/Heap/Closures.hs:23:1: error:
> Could not find module `GHC.Exts.Heap.InfoTableProf'
> It is a member of the hidden package `ghc-heap-8.5'.
> You can run `:set -package ghc-heap' to expose it.
> (Note: this unloads all the modules in the current scope.)
> Use -v to see a list of the files searched for.
> |
> 23 | import GHC.Exts.Heap.InfoTableProf
> | ^^
> make[1]: *** [libraries/ghc-heap/ghc.mk:4:
> libraries/ghc-heap/dist-install/build/GHC/Exts/Heap/Closures.p_o] Error 1
> make: *** [Makefile:127: all] Error 2
>
> For reference, here's my shell.nix:
>
> { nixpkgs ? import {}, compiler ? "ghcHEAD" }:
>
> let
> inherit (nixpkgs) pkgs;
> ghc = pkgs.haskell.packages.${compiler}.ghc;
> in
> with nixpkgs; lib.overrideDerivation ghc
> (drv: {
> name = "ghc-dev";
> nativeBuildInputs = drv.nativeBuildInputs ++ [
> arcanist
> git
> python36Packages.sphinx
> texlive.combined.scheme-basic
> ];
> })
>
> Any help would be appreciated.
>
> Thanks
> Sean G
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
