- ghc-devs - Haskell.org

how does a CAF become unreachable?
by Norman Ramsey 12 Oct '21

12 Oct '21

I spent the afternoon spelunking through some code and the Commentary, and I'm wondering how a CAF becomes unreachable. I gather it might have to do with GHC floating a static expression out of a context until it becomes a CAF, but I'm still not seeing how a CAF could at one point be reachable, then dynamically become unreachable. Can anyone show an example? Norman

2 1

where to go for HLS details?
by Norman Ramsey 12 Oct '21

12 Oct '21

Where is the place to go to talk details of the Haskell Language Server? I'm using the HLS with the GHC I have compiled from HEAD, and I am sitting on a number of difficulties: - When a project is compiled against a Stage 1 `base` library (as opposed to the one shipped with the bootstrap compiler), I am not always getting the documentation I expect. - The HLint part of the HLS seems to struggle finding modules in nested directories. - I cannot seem to get the `hiedb` command to index any files. - I'd like to set up the HLS to get to documentation via an HTTP-ish URL rather than the file:// URL that it is currently using, so that `doc-index.json` can be loaded successfully. I'm not quite ready to open a Github issue for any of these troubles just yet, but I'm not sure I can make progress on my own. Where is a good place to go for help? Norman

4 5

To allow deriving poly-kinded Generic1 instances
by Fumiaki Kinoshita 12 Oct '21

12 Oct '21

I was hacking GHC to see if it's able to derive Generic1 instance for datatypes with kind (Type -> Type) -> Type by omitting some checks. I noticed that the type parameter is substituted by GHC.Types.Any, preventing higher-kinded instances from typechecking. I found a comment implying that this is intentional; in GHC.Tc.Deriv.Generic.hs:977, Alternatively, we could have avoided this problem by expanding all type synonyms on the RHSes of Rep1 instances. But we might blow up the size of these types even further by doing this, so we choose not to do so. It wasn't obvious to me if binding a parameter in the type synonym instance declaration of Rep1 cause problems, because that's what I'd do if I were to define an instance by hand. Is there any offending example? I'm also trying to make such change myself (it doesn't add a type parameter and I'm not sure why) https://gitlab.haskell.org/fumieval/ghc/-/commit/bfe7766af80d90590b6b032d18…

1 0

help validating a modified compiler?
by Norman Ramsey 12 Oct '21

12 Oct '21

I've made a minor change to GHC, and before submitting a PR, I'd like to validate the change. But I don't really know how to interpret the output of the `validate` script. Mine runs for about 40 minutes and then ends in an error: # We are installing wrappers to programs by searching corresponding # wrappers. If wrapper is not found, we are attaching the common wrapper # to it. This implementation is a bit hacky and depends on consistency # of program names. For hadrian build this will work as programs have a # consistent naming procedure. if [ -L wrappers/ghc ]; then echo "ghc is a symlink"; fi ghc is a symlink cp: target 'dir/bin/ghc' is not a directory make: *** [Makefile:197: install_wrappers] Error 1 ________________________________________________________ Executed in 39.60 mins fish external usr time 146.65 mins 0.00 millis 146.65 mins sys time 9.55 mins 1.60 millis 9.55 mins I'm in the process of trying `validate` on a fresh checkout, but at 40 minutes per shot, I feel like I might be on the wrong track. Should I just create a merge request and rely on CI for the validation? Or do something else? Norman

3 3

-O* does more than what's in optLevelFlags?
by Erdi, Gergo 11 Oct '21

11 Oct '21

PUBLIC What is set by -O* that is not included in optLevelFlags? I would have thought that setting all the flags implied by, e.g., -O1, would be the same as setting -O1 itself. But this is not the case! Here are all the flags for O1 from optLevelFlags: Opt_DoLambdaEtaExpansion Opt_DoEtaReduction Opt_LlvmTBAA Opt_CallArity Opt_Exitification Opt_CaseMerge Opt_CaseFolding Opt_CmmElimCommonBlocks Opt_CmmSink Opt_CmmStaticPred Opt_CSE Opt_StgCSE Opt_EnableRewriteRules Opt_FloatIn Opt_FullLaziness Opt_IgnoreAsserts Opt_Loopification Opt_CfgBlocklayout Opt_Specialise Opt_CrossModuleSpecialise Opt_InlineGenerics Opt_Strictness Opt_UnboxSmallStrictFields Opt_CprAnal Opt_WorkerWrapper Opt_SolveConstantDicts Opt_NumConstantFolding And here are the ones that are set by O0 (the default) but not by O1: Opt_IgnoreInterfacePragmas Opt_OmitInterfacePragmas So I expected that the following two invocations of GHC would be equivalent: 1. ghc -O1 2. ghc -fdo-lambda-eta-expansion -fdo-eta-reduction -fllvm-tbaa -fcall-arity -fexitification -fcase-merge -fcase-folding -fcmm-elim-common-blocks -fcmm-sink -fcmm-static-pred -fcse -fstg-cse -fenable-rewrite-rules -ffloat-in -ffull-laziness -fignore-asserts -floopification -fblock-layout-cfg -fspecialise -fcross-module-specialise -finline-generics -fstrictness -funbox-small-strict-fields -fcpr-anal -fworker-wrapper -fsolve-constant-dicts -fnum-constant-folding -fno-ignore-interface-pragmas -fno-omit-interface-pragmas However, just by observing the output of -dshow-passes, I can see that while -O1 applies all these optimizations, the second version does NOT, even though I have turned on each and every one of them one by one. Looking at compiler/GHC/Driver/Session.hs, it is not at all clear that -O* should do more than just setting the flags from optLevelFlags. What other flags are implied by -O*? This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

3 6

Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*)
by Erdi, Gergo 11 Oct '21

11 Oct '21

PUBLIC PUBLIC Hi, Thanks! Originally I was going to reply to this saying that my transformation isn't running in CoreM so where do I get that environment from, but then I realized I can just build it from the md_insts field of ModDetails. However, after thinking more about it, I also realized that I shouldn't ever really need to conjure up dictionaries from thin air: the whole reason I am making a specific specialization of an overloaded function is because I found somewhere a call at that type. But then, that call also gives me the dictionary! Of course at this point, this sounds exactly like what GHC already does in `specProgram`. So maybe I should be able to just use that? Unfortunately, my initial testing seems to show that even if I run `specBind` manually on my whole-program collected CoreProgram, it doesn't do the work I would expect from it! In the following example, I have only kept the definitions that are relevant. Before specialisation, I have the following whole-program Core: (>>=) :: forall (m :: * -> *) a b. Monad m => m a -> (a -> m b) -> m b [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=<S(LSL),U(A,U,A)>] (>>=) = \ (@(m :: * -> *)) (v_sGm [Occ=Once1!] :: Monad m) -> case v_sGm of { C:Monad _ [Occ=Dead] v_sGp [Occ=Once1] _ [Occ=Dead] -> v_sGp } $dm>> :: forall (m :: * -> *) a b. Monad m => m a -> m b -> m b [GblId, Arity=3, Unf=OtherCon []] $dm>> = \ (@(m :: * -> *)) ($dMonad [Occ=Once1] :: Monad m) (@a) (@b) (ma [Occ=Once1] :: m a) (mb [Occ=OnceL1] :: m b) -> let { sat_sGQ [Occ=Once1] :: a -> m b [LclId] sat_sGQ = \ _ [Occ=Dead] -> mb } in >>= @m $dMonad @a @b ma sat_sGQ C:Monad [InlPrag=NOUSERINLINE CONLIKE] :: forall (m :: * -> *). Applicative m -> (forall a b. m a -> (a -> m b) -> m b) -> (forall a b. m a -> m b -> m b) -> Monad m [GblId[DataCon], Arity=3, Caf=NoCafRefs, Cpr=m1, Unf=OtherCon []] C:Monad = \ (@(m :: * -> *)) (eta_B0 [Occ=Once1] :: Applicative m) (eta_B1 [Occ=Once1] :: forall a b. m a -> (a -> m b) -> m b) (eta_B2 [Occ=Once1] :: forall a b. m a -> m b -> m b) -> C:Monad @m eta_B0 eta_B1 eta_B2 $fMonadIO [InlPrag=NOUSERINLINE CONLIKE] :: Monad IO [GblId[DFunId]] $fMonadIO = C:Monad @IO $fApplicativeIO bindIO $fMonadIO_$c>>; $fMonadIO_$c>> [Occ=LoopBreaker] :: forall a b. IO a -> IO b -> IO b [GblId] $fMonadIO_$c>> = \ (@a) (@b) -> $dm>> @IO $fMonadIO @a @b; sat_sHr :: IO () [LclId] sat_sHr = returnIO @() () sat_sHq :: IO () [LclId] sat_sHq = returnIO @() () main :: IO () [GblId] main = $fMonadIO_$c>> @() @() sat_sHq sat_sHr Now I pass this to GHC's `specBind`, but the output is exactly the same as the input! (or it's close enough that I can't spot the difference). (>>=) :: forall (m :: * -> *) a b. Monad m => m a -> (a -> m b) -> m b [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=<S(LSL),U(A,U,A)>] (>>=) = \ (@(m :: * -> *)) (v_sGm [Occ=Once1!] :: Monad m) -> case v_sGm of { C:Monad _ [Occ=Dead] v_sGp [Occ=Once1] _ [Occ=Dead] -> v_sGp } $dm>> :: forall (m :: * -> *) a b. Monad m => m a -> m b -> m b [GblId, Arity=3, Unf=OtherCon []] $dm>> = \ (@(m :: * -> *)) ($dMonad [Occ=Once1] :: Monad m) (@a) (@b) (ma [Occ=Once1] :: m a) (mb [Occ=OnceL1] :: m b) -> let { sat_MHt [Occ=Once1] :: a -> m b [LclId] sat_MHt = \ _ [Occ=Dead] -> mb } in >>= @m $dMonad @a @b ma sat_MHt C:Monad [InlPrag=NOUSERINLINE CONLIKE] :: forall (m :: * -> *). Applicative m -> (forall a b. m a -> (a -> m b) -> m b) -> (forall a b. m a -> m b -> m b) -> Monad m [GblId[DataCon], Arity=3, Caf=NoCafRefs, Cpr=m1, Unf=OtherCon []] C:Monad = \ (@(m :: * -> *)) (eta_B0 [Occ=Once1] :: Applicative m) (eta_B1 [Occ=Once1] :: forall a b. m a -> (a -> m b) -> m b) (eta_B2 [Occ=Once1] :: forall a b. m a -> m b -> m b) -> C:Monad @m eta_B0 eta_B1 eta_B2 $fMonadIO [InlPrag=NOUSERINLINE CONLIKE] :: Monad IO [GblId[DFunId]] $fMonadIO = C:Monad @IO $fApplicativeIO bindIO $fMonadIO_$c>>; $fMonadIO_$c>> [Occ=LoopBreaker] :: forall a b. IO a -> IO b -> IO b [GblId] $fMonadIO_$c>> = \ (@a) (@b) -> $dm>> @IO $fMonadIO @a @b; sat_sHr :: IO () [LclId] sat_sHr = returnIO @() () sat_sHq :: IO () [LclId] sat_sHq = returnIO @() () main :: IO () [GblId] main = $fMonadIO_$c>> @() @() sat_sHq sat_sHr Why is that? I would have expected that the call chain main >-> $fMonadIO_$c>> >-> $dm>> would have resulted in a specialization along the lines of: $dm>>_IO :: forall a b. IO a -> IO b -> IO b >>=_IO :: forall a b. IO a -> (a -> IO b) -> IO b With appropriate definitions that can then be simplified away. But none of this seems to happen -- $dm>> doesn't get an IO-specific version, and so $fMonadIO_$c>> still ends up with a dictionary-passing call to $dm>>. Isn't this exactly the situation that the specialiser is supposed to eliminate? Thanks, Gergo From: Simon Peyton Jones <simonpj(a)microsoft.com> Sent: Monday, October 4, 2021 7:29 PM To: Erdi, Gergo <Gergo.Erdi(a)sc.com> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com>; GHC <ghc-devs(a)haskell.org> Subject: [External] RE: Instantiation of overloaded definition *in Core* PUBLIC You can look it up in the class instance environment, which the Simplifier does have access to it. That's relatively easy when you have a simple dictionary like (Monad IO). But if you want (Eq [Int]) you first of all have to look up the (Eq [a]) dictionary, then the Eq Int dictionary, and apply the former to the latter. We don't (yet) have a simple API to do that, although it would not be hard to create one. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj(a)microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones(a)gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>.) From: ghc-devs <ghc-devs-bounces(a)haskell.org<mailto:ghc-devs-bounces@haskell.org>> On Behalf Of Erdi, Gergo via ghc-devs Sent: 04 October 2021 10:30 To: 'GHC' <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> Cc: Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com<mailto:Raphael.Montelatici@sc.com>> Subject: Instantiation of overloaded definition *in Core* PUBLIC Hi, I'd like to instantiate Core definitions. For example, suppose I have the following Core definition: foo :: forall m a b. Monad m => m a -> m b -> m b foo = \ @m ($d :: Monad m) @a @b (ma :: m a) (mb :: m b) -> ... Now let's say I'd like to instantiate it for m ~ IO. It is quite straightforward to go from the above to: foo_IO_0 :: forall a b. Monad IO => IO a -> IO b -> IO b foo_IO_0 = \ ($d :: Monad IO) @a @b (ma :: IO a) (mb :: IO b) -> ... However, I would like to go all the way to: foo_IO :: forall a b. IO a -> IO b -> IO b foo_IO = \ @a @b (ma :: IO a) (mb :: IO b) -> ... Because instances are coherent, it should be sound to replace all occurrences of $d with "the" dictionary for Monad IO. However, the places I've found for this kind of query seem to live in the typechecker. How do I access this information while working with Core? Thanks, Gergo This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

3 6

Why can't arguments be levity polymorphic for inline functions?
by Clinton Mead 08 Oct '21

08 Oct '21

Hi All Not sure if this belongs in ghc-users or ghc-devs, but it seemed devy enough to put it here. Section 6.4.12.1 <https://downloads.haskell.org/~ghc/9.0.1/docs/html/users_guide/exts/levity_…> of the GHC user manual points out, if we allowed levity polymorphic arguments, then we would have no way to compile these functions, because the code required for different levites is different. However, if such a function is {-# INLINE #-} or {-# INLINABLE #-} there's no need to compile it as it's full definition is in the interface file. Callers can just compile it themselves with the levity they require. Indeed callers of inline functions already compile their own versions even without levity polymorphism (for example, presumably inlining function calls that are known at compile time). The only sticking point to this that I could find was that GHC will only inline the function if it is fully applied <https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/pragmas.…>, which suggests that the possibility of partial application means we can't inline and hence need a compiled version of the code. But this seems like a silly restriction, as we have the full RHS of the definition in the interface file. The caller can easily create and compile it's own partially applied version. It should be able to do this regardless of levity. It seems to me we're okay as long as the following three things aren't true simultaneously: 1. Blah has levity polymorphic arguments 2. Blah is exported 3. Blah is not inline If a function "Blah" is not exported, we shouldn't care about levity polymorphic arguments, because we have it's RHS on hand in the current module and compile it as appropriate. And if it's inline, we're exposing it's full RHS to other callers so we're still fine also. Only when these three conditions combine should we give an error, say like: "Blah has levity polymorphic arguments, is exported, and is not inline. Please either remove levity polymorphic arguments, not export it or add an {-# INLINE #-} or {-# INLINABLE #-} pragma. I presume however there are some added complications that I don't understand, and I'm very interested in what they are as I presume they'll be quite interesting. Thanks, Clinton

7 10

Temporary Outage
by Ben Gamari 07 Oct '21

07 Oct '21

Hi all, You may notice that currently there are numerous CI failures due to apparent network issues. This appears to be due to a network outage on the part of our hosting providing. Further updates are available from Packet [1]. Hopefully the issue will be resolved within the next few hours. Cheers, - Ben [1] https://status.equinixmetal.com/

1 0

Perf backtrace support.
by Andreas Klebinger 07 Oct '21

07 Oct '21

Hello Devs, as some of you know I've recently been working on #8272. The goal being to use the machine stack register for the STG stack as a means to get perf backtraces. I've succeeded in making a branch that works for the first part but have so far been unable to get perf to generate proper back traces. For various reasons I will stop looking at that particular issue. So if anyone feels interested in figuring out where the interaction between our dwarf info and perf unwinding the stack goes wrong please take a look! There is more information on the ticket. Cheers Andreas

1 0

Re: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*)
by Erdi, Gergo 06 Oct '21

06 Oct '21

INTERNAL I see. That will be a bit more involved to try out, because I don't have a ModGuts at hand -- I only have the ModDetails, and the collected CoreProgram from the whole program. But it seems `specProgram` only really uses the rules and the binds from the `ModGuts`, so I should be all right. But one thing I can easily try is just printing the UsageDetails as returned by the specBinds part of specProgram, and that seems empty. So if the actual work of specProgram happens by generating rules in specImports, how will specImports know what rules to generate, from an empty UsageDetails? -----Original Message----- From: Matthew Pickering <matthewtpickering(a)gmail.com> Sent: Wednesday, October 6, 2021 4:24 PM To: Erdi, Gergo <Gergo.Erdi(a)sc.com> Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com>; GHC <ghc-devs(a)haskell.org> Subject: [External] Re: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*) I think you need to run at least one simplifier pass as the specialisations are applied via rules (created by specProgram). This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

1 0