August 2014 - ghc-devs

Why isn't ($) inlining when I want?
by David Feuer 30 Aug '14

30 Aug '14

tl;dr I added a simplifier run with inlining enabled between specialization and floating out. It seems incapable of inlining saturated applications of ($), and I can't figure out why. These are inlined later, when phase 2 runs. Am I running the simplifier wrong or something? I'm working on this simple little fusion pipeline: {-# INLINE takeWhile #-} takeWhile p xs = build builder where builder c n = foldr go n xs where go x r = if p x then x `c` r else n foo c n x = foldr c n . takeWhile (/= (1::Int)) $ [-9..10] There are some issues with the enumFrom definition that break things. If I use a fusible unfoldr that produces some numbers instead, that issue goes away. Part of that problem (but not all of it) is that the simplifier doesn't run to apply rules between specialization and full laziness, so there's no opportunity for the specialization of enumFromTo to Int to trigger the rewrite to a build form and fusion with foldr before full laziness tears things apart. The other problem is that inlining doesn't happen at all before full laziness, so things defined using foldr and/or build aren't actually exposed as such until afterwards. Therefore I decided to try adding a simplifier run with inlining between specialization and floating out: runWhen do_specialise CoreDoSpecialising, runWhen full_laziness $ CoreDoSimplify max_iter (base_mode { sm_phase = InitialPhase , sm_names = ["PostGentle"] , sm_rules = rules_on , sm_inline = True , sm_case_case = False }), runWhen full_laziness $ CoreDoFloatOutwards FloatOutSwitches { floatOutLambdas = Just 0, floatOutConstants = True, floatOutPartialApplications = False }, The weird thing is that for some reason this doesn't inline ($), even though it appears to be saturated. Using the modified thing with (my version of) unfoldr: foo c n x = (foldr c n . takeWhile (/= (1::Int))) $ unfoldr (potato 10) (-9) potato :: Int -> Int -> Maybe (Int, Int) potato n m | m <= n = Just (m, m) | otherwise = Nothing I get this out of the specializer: foo foo = \ @ t_a1Za @ c_a1Zb c_a1HT n_a1HU _ -> $ (. (foldr c_a1HT n_a1HU) (takeWhile (let { ds_s21z ds_s21z = I# 1 } in \ ds_d1Zw -> neInt ds_d1Zw ds_s21z))) (let { n_s21x n_s21x = I# 10 } in unfoldr (\ m_a1U7 -> case leInt m_a1U7 n_s21x of _ { False -> Nothing; True -> Just (m_a1U7, m_a1U7) }) ($fNumInt_$cnegate (I# 9))) and then I get this out of my extra simplifier run: foo foo = \ @ t_a1Za @ c_a1Zb c_a1HT n_a1HU _ -> $ (\ x_a20f -> foldr (\ x_a1HR r_a1HS -> case case x_a1HR of _ { I# x_a20R -> tagToEnum# (case x_a20R of _ { __DEFAULT -> 1; 1 -> 0 }) } of _ { False -> n_a1HU; True -> c_a1HT x_a1HR r_a1HS }) n_a1HU x_a20f) (let { b'_a1ZS b'_a1ZS = $fNumInt_$cnegate (I# 9) } in $ (build) (\ @ b1_a1ZU c_a1ZV n_a1ZW -> letrec { go_a1ZX go_a1ZX = \ b2_a1ZY -> case case case b2_a1ZY of _ { I# x_a218 -> tagToEnum# (<=# x_a218 10) } of _ { False -> Nothing; True -> Just (b2_a1ZY, b2_a1ZY) } of _ { Nothing -> n_a1ZW; Just ds_a203 -> case ds_a203 of _ { (a1_a207, new_b_a208) -> c_a1ZV a1_a207 (go_a1ZX new_b_a208) } }; } in go_a1ZX b'_a1ZS)) That is, neither the $ in the code nor the $ that was inserted when inlining unfoldr got inlined themselves, even though both appear to be saturated. As a result, foldr/build doesn't fire, and full laziness tears things apart. Later on, in simplifier phase 2, $ gets inlined. What's preventing this from happening in the PostGentle phase I added? David Feuer

4 11

build fixes
by Simon Peyton Jones 30 Aug '14

30 Aug '14

I've pushed patches that should finally fix the build. (including improved performance in the compiler itself!) Sorry about the breakage yesterday Simon

4 5

HEADS UP: full rebuild necessary
by Edward Z. Yang 30 Aug '14

30 Aug '14

Duncan has landed his changes to remove GHC's dep on Cabal, so you'll need to do a clean and full rebuild once you pull from master. Cheers, Edward

3 4

RE: Fusion
by Simon Peyton Jones 30 Aug '14

30 Aug '14

I have added a section "Ticky-ticky quick start" to our ticky-ticky profiling page, to explain how I go about dealing with the problem you describe https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky Simon | -----Original Message----- | From: David Feuer [mailto:david.feuer@gmail.com] | Sent: 20 August 2014 09:33 | To: Simon Peyton Jones | Subject: Re: Fusion | | I'll be happy to try to expand it with some examples. I'm wondering if | you could help me figure something out: the (simple) cons/build rule | we discussed, along with the similar cons/augment rule, | | "cons/build" forall (x::a) (g::forall b . (a->b->b)->b->b) . x : | build g = build (\c n -> c x (g c n)) | "cons/augment" forall (x::a) (g::forall b . (a->b->b)->b->b) | (xs::[a]) . x : augment g xs = augment (\c n -> c x (g c n)) xs | | somehow *increase* allocation substantially (11.7%) in the "event" | NoFib test, and also significantly (3.6%) in constraints, somewhat | (2.4%) in nucleic2 [remember this] and 1.4% in ansi. I am having a | heck of a time trying to figure out how to track these down, and | burning loads of time recompiling GHC over and over again. On the flip | side of things, the wang test reduces allocation by 45.8% if I use | these rules (both of which fire), but only when I also use -fsimple- | list-literals for nofib/spectral/hartel/nucleic2/Main.hs. | nucleic2 still performs a little more allocation. | | On Wed, Aug 20, 2014 at 2:56 AM, Simon Peyton Jones | <simonpj(a)microsoft.com> wrote: | > Great start, thank you. Can I suggest that for each question you | give | > a concrete example? Otherwise only experts, who already know a lot | about | > rules, will understand the question, let alone the answer. I’d be | happy to | > take another look then. | > | > | > Simon | > | > | > | > From: David Feuer [mailto:david.feuer@gmail.com] | > Sent: 19 August 2014 23:30 | > To: Simon Peyton Jones | > Cc: Haskell Libraries | > Subject: Re: Fusion | > | > | > | > I've started a page at | > https://ghc.haskell.org/trac/ghc/wiki/FoldrBuildNotes | > Please feel free to add, correct, etc. | > | > On Aug 19, 2014 3:10 AM, "Simon Peyton Jones" | <simonpj(a)microsoft.com> wrote: | > | > David | > | > You've been doing all this work on improving fusion, and you | probably | > have a very good idea now about how it works, and how GHC's | libraries | > use phases and RULES to achieve it. A kind of design pattern, if you | > like; tips and tricks. | > | > I wonder if you'd feel able to write a GHC wiki page describing what | > you have learned, with examples and explanation about why it is done | that way. | > If you did this, someone who follows in your footsteps wouldn't need | > to re-learn everything. And maybe someone will say "oh, there's one | > pattern you have omitted, here it is". | > | > Thanks | > | > Simon

2 1

Moving Haddock *development* out of GHC tree
by Mateusz Kowalczyk 29 Aug '14

29 Aug '14

Hello, A slightly long e-mail but I ask that you voice your opinion if you ever changed GHC API. You can skim over the details, simply know that it saves me vast amount of time, allows me to try and find contributors and doesn't impact GHC negatively. It seems like a win-win scenario for GHC and Haddock. GHC team's workflow does not change and will not require any new commitment: I do all the work and I think it's a 1 line change in sync-all when transition is ready. Here it is: It is no secret that many core Haskell projects lack developer hands and Haddock is no exception: the current maintainers are Simon Hengel and myself. Simon does not have much time so currently all the issues and updates are up to me. Ideally I would like if some more people could come and hack on Haddock but there are a couple of problems with trying to recruit folk for this: 1. Interacting with GHC API is not the easiest thing. This is Haddock's problem but I thought I'd mention it here. 2. Haddock resides directly in the GHC tree and it is currently *required* that it compiles with GHC HEAD. This is a huge barrier of entry for anyone: today I wanted to make a fairly simple change but it still took me 3 validate runs to be at least somewhat confident that I didn't break much in GHC. On top of this I had help from Edward Z. Yang on IRC and information from him on what the issue exactly was. If I was to do everything alone it would have taken even more validates. A validate is not fast on machine by any means, it takes an hour or two. Here is what I want to do unless there are major objections: I want to move the active development away from GHC tree. Below is how it would work. For simplicity please imagine that we have *just* released 7.8.3. * Haddock development would concentrate on supporting the last public release of GHC: I stop developing against GHC HEAD and currently would develop against 7.8.3. * GHC itself checks out Haddock as a submodule as it does now. The only difference is that it points at whatever commit worked last. Let us assume it is the Haddock 2.14.3 release commit. The vital difference from current state is that GHC will no longer track changes in master branch. * Now when GHC API changes things proceed as they normally do: whoever is responsible for the changes, pops into the Haddock submodule applies the patches necessary for Haddock to build with HEAD and everyone is happy. What does *not* happen is these patches don't go into master: I ignore them and keep working with 7.8.3. * When a GHC release rolls around, I update Haddock to work with the new API so that people with new release can still use it. Once it works against new API, GHC can start tracking from that commit onwards and proceed as usual. Here are the advantages: * I don't have to work against GHC HEAD. This means I don't have to build GHC HEAD and I don't need to worry about GHC API changes. I don't waste 2-4 hours building before hacking and validating after hacking to make any minor changes and to make sure I haven't broken anything. * More importantly, anyone who wants to write a patch for Haddock can now do so easily, all they need is recent compiler rather than being forced to build HEAD. Building and validating against HEAD is a **huge** barrier of entry. * I only have to care about GHC API changes once a release and not twice a week. I think PatternSynonyms have changed 4 times in a month but the end result at release time is the same and that's what people care about. * It is less work for anyone changing GHC API: they only have to deal with their own changes and not my changes which add features or whatever. * If I break something in Haddock HEAD, GHC is not affected. * If Haddock's binary interface doesn't change, we may even allow more versions of GHC be compatible through CPP and other such trickery. If we were to do it today, it would be an increased burden on the GHC team to deal with those. * I can release as often as I want against the same compiler version. Currently doing this requires backporting features (see v2.14 branch) which is a massive pain. I no longer have to tell the users ‘yes, your bug is fixed but to get it you need to compile GHC HEAD or wait 6-12 months until next GHC release’. I have to do this a lot. Here are the disadvantages and why I think they don't make a big difference: * GHC HEAD doesn't get any new-and-cool features that we might implement. I say this doesn't matter because no one uses varying GHC HEAD versions to develop actual software, documentation and all. What I mean to say is that the only user of the Haddock that's developed in GHC tree is GHC itself. The only case where GHC actually used in-tree Haddock was when Herbert generated documentation for base-4.7 early for me to eye before the release. Even this doesn't matter because so close to the release I'll already have the existing GHC API integrated anyway. Again, it does not matter if GHC HEAD itself doesn't get pretty operator rendering or whatever right when I implement it because no one cares about it until it's release time. I know that many people simply HADDOCK_DOCS=NO to save time. The actual users only care about Haddock that works with 7.6.x, 7.8.x, 7.10.x; only GHC cares about in-betweens and only for the purpose of being able to build and validate. * GHC team can't easily contribute features and get the back immediately. In part it doesn't matter because of the previous point and in the last year or so there were no features contributed directly from GHC except those necessary to keep Haddock compiling. This just means there's no demand for such close relationship. * Haddock-affecting changes in GHC parser don't ‘take effect’ straight away. This is my loss and considering the infrequency at which such changes happen, it's a tiny price to pay to have to wait until release. * …that's it, no other disadvantages that I can think of, but that's why I'm sending it to the list to review! What's worth mentioning is that the no-external-dependencies thing still applies because even though we no longer need to compile against HEAD, we still need to compile against the tree at release time. In summary: My life gets easier because I stop wasting it on playing with whole GHC tree, GHC team's life gets easier because they don't have to deal with the changes I make. My life gets even easier because I only have to make big API updates once a release. I can actually start looking for contributors. When a release rolls around, GHC and Haddock ‘meet up’, we make sure it all works, release happens, GHC starts tracking from that point and we part ways until the next release. What do you think? If there are no major objections in one week then I will assume I am good to go with this. Transition from current setup: If I receive some patches I was promised then I will then make a 2.14.4 bugfix/compat release make sure that master is up to date and then create something like GHC-tracking branch from master and track that. I will then abandon that branch and not push to it unless it is GHC release time. The next commit in master will bring Haddock to a state where it works with 7.8.3: yes, this means removing all new API stuff until 7.10 or 7.8.4 or whatever. GHC API changes go onto GHC-tracking while all the stuff I write goes master. When GHC makes a release or is about to, I make master work with that and make GHC-tracking point to that instead. Thanks! -- Mateusz K.

10 30

Does the 'stage=2' setting not work anymore in build.mk?
by Dr. ERDI Gergo 29 Aug '14

29 Aug '14

Hi, I tried setting 'stage=2' in my mk/build.mk file, but the stage 1 compiler is still getting rebuilt (and of course this causes the stage 2 compiler to be rebuilt from scratch...). I am using BuildFlavour=devel2. What am I missing? Thanks, Gergo

3 7

clang warnings with unregisterised
by Gabor Greif 29 Aug '14

29 Aug '14

Devs, I have built an UNREGISTERISED GHC, and the C-compiler used behind the scenes is clang. Now I get literally millions of warnings of the below kind: +/var/folders/k9/fj_1d5h17m7c4gbyp2srqrhm0000gq/T/ghc11601_0/ghc11601_4.hc:688:1: + warning: attribute declaration must precede definition [-Wignored-attributes] +II_(s4Vv_closure); +^ + +/Users/ggreif/ghc-head/includes/Stg.h:213:63: + note: expanded from macro 'II_' +#define II_(X) static StgWordArray (X) GNU_ATTRIBUTE(aligned (8)) + ^ + +/Users/ggreif/ghc-head/includes/Stg.h:175:42: + note: expanded from macro 'GNU_ATTRIBUTE' +#define GNU_ATTRIBUTE(at) __attribute__((at)) + ^ + +/var/folders/k9/fj_1d5h17m7c4gbyp2srqrhm0000gq/T/ghc11601_0/ghc11601_4.hc:588:16: + note: previous definition is here +static StgWord s4Vv_closure[] = { + ^ It seems like the "II_" and "EI_" prototypes *follow* the real thing, and because clang is more picky with attribute placement, we get all those warnings. compiler/cmm/PprC.hs:pprExternDecl is the function that puts together the "II_(...)" and "EI_(...)", but where does the "static StgWord s4Vv_closure[] = {" come from? I just want to flip the order of their occurrence. Thanks, Gabor

2 1

Raft of optimizer changes
by David Feuer 29 Aug '14

29 Aug '14

On Thu, Aug 28, 2014 at 8:00 AM, simonpj wrote > I've just pushed a bunch of Core-to-Core optimisation changes that have been sitting in my tree for ages. The aggregate effect on nofib is very modest, but they are mostly aimed at corner cases, and consolidation. Thanks for trying to do that. Unfortunately, this seems to have introduced some other sort of corner case. Making reverse (and unfoldr, but I'm pretty sure that's unused and hence irrelevant) fusible now makes n-body allocate 1100% more. I haven't looked into why yet. David

1 0

Why isn't (.) CONLIKE?
by David Feuer 29 Aug '14

29 Aug '14

Speaking of CONLIKE, I'd have expected (.) to be CONLIKE, since it looks much like a constructor. Would that be bad for some reason? Or is it already treated well enough not to need that? On Aug 28, 2014 11:56 AM, "Simon Peyton Jones" <simonpj(a)microsoft.com> wrote: > Actually the CONLIKE thing still allows them to float, but makes RULES > continue to work even though they’ve been floated. See the user manual. > > > > *From:* Dan Doel [mailto:dan.doel@gmail.com] > *Sent:* 28 August 2014 16:48 > *To:* Simon Peyton Jones > *Cc:* John Lato; David Feuer; ghc-devs > *Subject:* Re: Why isn't ($) inlining when I want? > > > > Okay, so marking things as conlike will make GHC avoid floating them? > > I'm pretty sure that in most vector cases, this is a straight > pessimization. There is no way to avoid the extra allocation of integers, > because most intermediate vector types are unboxed, so the integer > allocation will be performed regardless. Only boxed vectors might be an > exception. > > > > On Thu, Aug 28, 2014 at 4:14 AM, Simon Peyton Jones <simonpj(a)microsoft.com> > wrote: > > I remember doing some work on the “floating of constant lists” question. > > > > First, [1..n] turns into (enumFromTo 1 n), and if enumFromTo was > expensive, then sharing it might be a good plan. So GHC would have to know > that it was cheap. > > > > I did experiment with “cheapBuild” see > https://ghc.haskell.org/trac/ghc/ticket/7206, but as you’ll see there, > the results were equivocal. By duplicating the [1..n] we were allocating > two copies of (I# 4), (I# 5) etc, and that increased allocation and GC time. > > > > So it’s unclear, in general, whether in these examples it is better to > share the [1..n] between all calls of ‘loop’, or to duplicate it. > > > > All that said, Dan’s question of why X fuses and very-similar Y doesn’t > was a surprise to me; I’ll look into that. > > > Simon > > > > *From:* John Lato [mailto:jwlato@gmail.com] > *Sent:* 28 August 2014 00:17 > *To:* Dan Doel > *Cc:* Simon Peyton Jones; David Feuer; ghc-devs > > > *Subject:* Re: Why isn't ($) inlining when I want? > > > > I sometimes think the solution is to make let-floating apply in fewer > cases. I'm not sure we ever want to float out intermediate lists, the cost > of creating them is very small relative to the memory consumption if they > do happen to get shared. > > > > My approach is typically to mark loop INLINE. This very often results in > the code I want (with vector, which I use more than lists), but it is a big > hammer to apply. > > > > John > > > > On Thu, Aug 28, 2014 at 5:56 AM, Dan Doel <dan.doel(a)gmail.com> wrote: > > I think talking about inlining of $ may not be addressing the crux of > the problem here. > > The issue seems to be about functions like the one in the first message. > For instance: > > loop :: (Int -> Int) -> Int > > loop g = sum . map g $ [1..1000000] > > Suppose for argument that we have a fusion framework that would handle > this. The problem is that this does not actually turn into a loop over > integers, because the constant [1..1000000] gets floated out. It instead > builds a list/vector/whatever. > > By contrast, if we write: > > loop' :: Int > > loop' = sum . map (+1) $ [1..1000000] > > this does turn into a loop over integers, with no intermediate list. > Presumably this is due to there being no work to be saved ever by floating > the list out. These are the examples people usually test fusion with. > > And if loop is small enough to inline, it turns out that the actual code > that gets run will be the same as loop', because everything will get > inlined and fused. But it is also possible to make loop big enough to not > inline, and then the floating will pessimize the overall code. > > So the core issue is that constant floating blocks some fusion > opportunities. It is trying to save the work of building the structure more > than once, but fusion can cause the structure to not be built at all. And > the floating happens before fusion can reasonably be expected to work. > > Can anything be done about this? > > I've verified that this kind of situation also affects vector. And it > seems to be an issue even if loop is written: > > loop g = sum (map g [1..1000000]) > > -- Dan > > > > On Wed, Aug 27, 2014 at 3:38 PM, Simon Peyton Jones <simonpj(a)microsoft.com> > wrote: > > You'll have to do more detective work! In your dump I see "Inactive > unfolding $". So that's why it's not being inlined. That message comes > from CoreUnfold, line 941 or so. The Boolean active_unfolding is passed in > to callSiteInline from Simplify, line 1408 or so. It is generated by the > function activeUnfolding, defined in SimplUtils. > > But you have probably change the "CompilerPhase" data type, so I can't > guess what is happening. But if you just follow it through I'm sure you'll > find it. > > Simon > > > | -----Original Message----- > | From: David Feuer [mailto:david.feuer@gmail.com] > | Sent: 27 August 2014 17:22 > | To: Simon Peyton Jones > | Cc: ghc-devs > | Subject: Re: Why isn't ($) inlining when I want? > | > | I just ran that (results attached), and as far as I can tell, it > | doesn't even *consider* inlining ($) until phase 2. > | > | On Wed, Aug 27, 2014 at 4:03 AM, Simon Peyton Jones > | <simonpj(a)microsoft.com> wrote: > | > It's hard to tell since you are using a modified compiler. Try running > | with -ddump-occur-anal -dverbose-core2core -ddump-inlinings. That will > | show you every inlining, whether failed or successful. You can see the > | attempt to inline ($) and there is some info with the output that may > | help to explain why it did or did not work. > | > > | > Try that > | > > | > Simon > | > > | > | -----Original Message----- > | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of > | David > | > | Feuer > | > | Sent: 27 August 2014 04:50 > | > | To: ghc-devs; Carter Schonwald > | > | Subject: Why isn't ($) inlining when I want? > | > | > | > | tl;dr I added a simplifier run with inlining enabled between > | > | specialization and floating out. It seems incapable of inlining > | > | saturated applications of ($), and I can't figure out why. These are > | > | inlined later, when phase 2 runs. Am I running the simplifier wrong > | or > | > | something? > | > | > | > | > | > | I'm working on this simple little fusion pipeline: > | > | > | > | {-# INLINE takeWhile #-} > | > | takeWhile p xs = build builder > | > | where > | > | builder c n = foldr go n xs > | > | where > | > | go x r = if p x then x `c` r else n > | > | > | > | foo c n x = foldr c n . takeWhile (/= (1::Int)) $ [-9..10] > | > | > | > | There are some issues with the enumFrom definition that break things. > | > | If I use a fusible unfoldr that produces some numbers instead, that > | > | issue goes away. Part of that problem (but not all of it) is that the > | > | simplifier doesn't run to apply rules between specialization and full > | > | laziness, so there's no opportunity for the specialization of > | > | enumFromTo to Int to trigger the rewrite to a build form and fusion > | > | with foldr before full laziness tears things apart. The other problem > | > | is that inlining doesn't happen at all before full laziness, so > | things > | > | defined using foldr and/or build aren't actually exposed as such > | until > | > | afterwards. Therefore I decided to try adding a simplifier run with > | > | inlining between specialization and floating out: > | > | > | > | runWhen do_specialise CoreDoSpecialising, > | > | > | > | runWhen full_laziness $ CoreDoSimplify max_iter > | > | (base_mode { sm_phase = InitialPhase > | > | , sm_names = ["PostGentle"] > | > | , sm_rules = rules_on > | > | , sm_inline = True > | > | , sm_case_case = False }), > | > | > | > | runWhen full_laziness $ > | > | CoreDoFloatOutwards FloatOutSwitches { > | > | floatOutLambdas = Just 0, > | > | floatOutConstants = True, > | > | floatOutPartialApplications = False > | }, > | > | > | > | The weird thing is that for some reason this doesn't inline ($), even > | > | though it appears to be saturated. Using the modified thing with (my > | > | version of) unfoldr: > | > | > | > | foo c n x = (foldr c n . takeWhile (/= (1::Int))) $ unfoldr (potato > | 10) > | > | (-9) > | > | > | > | potato :: Int -> Int -> Maybe (Int, Int) > | > | potato n m | m <= n = Just (m, m) > | > | | otherwise = Nothing > | > | > | > | > | > | I get this out of the specializer: > | > | > | > | foo > | > | foo = > | > | \ @ t_a1Za @ c_a1Zb c_a1HT n_a1HU _ -> > | > | $ (. (foldr c_a1HT n_a1HU) > | > | (takeWhile > | > | (let { > | > | ds_s21z > | > | ds_s21z = I# 1 } in > | > | \ ds_d1Zw -> neInt ds_d1Zw ds_s21z))) > | > | (let { > | > | n_s21x > | > | n_s21x = I# 10 } in > | > | unfoldr > | > | (\ m_a1U7 -> > | > | case leInt m_a1U7 n_s21x of _ { > | > | False -> Nothing; > | > | True -> Just (m_a1U7, m_a1U7) > | > | }) > | > | ($fNumInt_$cnegate (I# 9))) > | > | > | > | > | > | and then I get this out of my extra simplifier run: > | > | > | > | foo > | > | foo = > | > | \ @ t_a1Za @ c_a1Zb c_a1HT n_a1HU _ -> > | > | $ (\ x_a20f -> > | > | foldr > | > | (\ x_a1HR r_a1HS -> > | > | case case x_a1HR of _ { I# x_a20R -> > | > | tagToEnum# > | > | (case x_a20R of _ { > | > | __DEFAULT -> 1; > | > | 1 -> 0 > | > | }) > | > | } > | > | of _ { > | > | False -> n_a1HU; > | > | True -> c_a1HT x_a1HR r_a1HS > | > | }) > | > | n_a1HU > | > | x_a20f) > | > | (let { > | > | b'_a1ZS > | > | b'_a1ZS = $fNumInt_$cnegate (I# 9) } in > | > | $ (build) > | > | (\ @ b1_a1ZU c_a1ZV n_a1ZW -> > | > | letrec { > | > | go_a1ZX > | > | go_a1ZX = > | > | \ b2_a1ZY -> > | > | case case case b2_a1ZY of _ { I# x_a218 -> > | > | tagToEnum# (<=# x_a218 10) > | > | } > | > | of _ { > | > | False -> Nothing; > | > | True -> Just (b2_a1ZY, b2_a1ZY) > | > | } > | > | of _ { > | > | Nothing -> n_a1ZW; > | > | Just ds_a203 -> > | > | case ds_a203 of _ { (a1_a207, new_b_a208) -> > | > | c_a1ZV a1_a207 (go_a1ZX new_b_a208) > | > | } > | > | }; } in > | > | go_a1ZX b'_a1ZS)) > | > | > | > | > | > | That is, neither the $ in the code nor the $ that was inserted when > | > | inlining unfoldr got inlined themselves, even though both appear to > | be > | > | saturated. As a result, foldr/build doesn't fire, and full laziness > | > | tears things apart. Later on, in simplifier phase 2, $ gets inlined. > | > | What's preventing this from happening in the PostGentle phase I > | added? > | > | > | > | David Feuer > | > | _______________________________________________ > | > | ghc-devs mailing list > | > | ghc-devs(a)haskell.org > | > | http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > >

2 1

Contributing To Haskell talk
by Joachim Breitner 29 Aug '14

29 Aug '14

Hi list, you might know that was I talked into^W^Wvolunteered to holding the “Contributing to GHC”¹ talk at HIW in 9 days. I’ll do it, but for some of the intended topics, I don’t feel like the best person to do it on my own. In particular, I was wondering if any of the active Phabricator proponents or users would be available to help me there, either during the preparation (which will happen at Göteborg; I’m currently distracted by the Debian Conference in Portland), or by performing a duet. Thanks, Joachim ¹ http://www.haskell.org/haskellwiki/HaskellImplementorsWorkshop/2014#Contrib… -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0