Re: stranal/sigs/UnsatFun
Richard Eisenberg writes: > These responses are helpful, thanks. > > Is there a primer for how to read the output? Or a small function that > produces the output that I could quickly reverse engineer? > > There is a suggestion to look at the core before and after my patch. > Is there a certain phase I should look at? What should I look for? > > And where in the GHC code base should I start looking to understand > this better? > > Sorry if these questions seem too easy -- I'm just out of my element > here. My hunch is that I need to update something in the strictness > analyzer to look through/around/beyond coercions somewhere. Any ideas > as to what that might be would be helpful! :) > You might also want to look at [1], which appears to offer a nice tour around the implementation. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Demand/RelevantParts signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: stranal/sigs/UnsatFun
Richard Eisenberg writes: > These responses are helpful, thanks. > > Is there a primer for how to read the output? Or a small function that > produces the output that I could quickly reverse engineer? > The Wiki is a good place to start although the description there is lacking a bit. [1] Relatedly, some time ago I started writing a blog article about various aspects of Core with the intent of presenting a document accessible to the average Haskeller with an interest in diving into the compilation pipeline. While it's quite far from done, it's perhaps worth putting up the current state of it. Here it is [2]. > There is a suggestion to look at the core before and after my patch. > Is there a certain phase I should look at? What should I look for? > It would be good to see the Core as it enters strictness analysis. > And where in the GHC code base should I start looking to understand > this better? > compiler/stranal I believe. Of course, take anything I have to say with a large grain of salt; Joachim's opinion is orders of magnitude better informed than mine in this area. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Demand [2] http://smart-cactus.org/~ben/posts/2015-01-19-understanding-ghc-core.html signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: stranal/sigs/UnsatFun
Hi Richard, Am Sonntag, den 29.11.2015, 22:16 -0500 schrieb Richard Eisenberg: > Is there a primer for how to read the output? there is https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Demand which I think is the most up-to-date-description of strictness signatures. All the papers out there, as far as I know, only cover some of the aspects of it. > Or a small function > that produces the output that I could quickly reverse engineer? Sorry, not sure what you mean :-| The pretty-printer for these is in compiler/basicTypes/Demand.hs. > There is a suggestion to look at the core before and after my patch. > Is there a certain phase I should look at? What should I look for? The strictness signature is calculated by the Demand Analyser, so I think -ddump-stranal is the right one. > And where in the GHC code base should I start looking to understand > this better? Definitely compiler/stranal/DmdAnal.lhs. > Sorry if these questions seem too easy -- I'm just out of my element > here. My hunch is that I need to update something in the strictness > analyzer to look through/around/beyond coercions somewhere. Any ideas > as to what that might be would be helpful! :) That’d be my hunch as well, but I’m not sure how to help more – besides building your branch and tracing through the code myself. If you are stuck or really do not feel like looking at that code, just should and I’ll see if I can detect whats wrong. But maybe for that it already suffices to see the core in both cases somewhere. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: stranal/sigs/UnsatFun
These responses are helpful, thanks. Is there a primer for how to read the output? Or a small function that produces the output that I could quickly reverse engineer? There is a suggestion to look at the core before and after my patch. Is there a certain phase I should look at? What should I look for? And where in the GHC code base should I start looking to understand this better? Sorry if these questions seem too easy -- I'm just out of my element here. My hunch is that I need to update something in the strictness analyzer to look through/around/beyond coercions somewhere. Any ideas as to what that might be would be helpful! :) Thanks, Richard On Nov 29, 2015, at 2:49 PM, Ben Gamari wrote: > Richard Eisenberg writes: > >> Hi devs, >> >> On my kind=type branch (D808), I have this test failure for >> stranal/sigs/UnsatFun: >> > Hmmm. I was curious and so took the opportunity to do a bit of digging. > This likely isn't helpful but you never know... > >> -UnsatFun.g: b >> +UnsatFun.g: > > It looks like the strictness analyzer can no longer see that `g` is > bottoming (hence the missing `b`), which unfortunately seems to be > exactly what this test is testing for. :( > > Moreover, the `B` changing to an `L` means that the demand analysis > can't see that any demand is made of the first argument. > >> -UnsatFun.h: >> +UnsatFun.h: > > This is the helper used by `g`. Again, it looks like something is going > awry here with strictness analysis as the argument which was previously > deemed "call-demand" is now just "strict". > >> -UnsatFun.g': >> +UnsatFun.g': >> >> -UnsatFun.h2: >> +UnsatFun.h2: > > This appears to be a very similar test which is likely failing for a > similar reason. > > Could you perhaps collect the Core for this test before and after your > patch? > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: stranal/sigs/UnsatFun
Richard Eisenberg writes: > Hi devs, > > On my kind=type branch (D808), I have this test failure for > stranal/sigs/UnsatFun: > Hmmm. I was curious and so took the opportunity to do a bit of digging. This likely isn't helpful but you never know... > -UnsatFun.g: b > +UnsatFun.g: It looks like the strictness analyzer can no longer see that `g` is bottoming (hence the missing `b`), which unfortunately seems to be exactly what this test is testing for. :( Moreover, the `B` changing to an `L` means that the demand analysis can't see that any demand is made of the first argument. > -UnsatFun.h: > +UnsatFun.h: This is the helper used by `g`. Again, it looks like something is going awry here with strictness analysis as the argument which was previously deemed "call-demand" is now just "strict". > -UnsatFun.g': > +UnsatFun.g': > > -UnsatFun.h2: > +UnsatFun.h2: This appears to be a very similar test which is likely failing for a similar reason. Could you perhaps collect the Core for this test before and after your patch? signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: stranal/sigs/UnsatFun
Hi, Am Sonntag, den 29.11.2015, 10:42 -0500 schrieb Richard Eisenberg: > On my kind=type branch (D808), I have this test failure for > stranal/sigs/UnsatFun: > > Strictness signatures > UnsatFun.$trModule: m > UnsatFun.f: b > -UnsatFun.g: b > -UnsatFun.g': > +UnsatFun.g: > +UnsatFun.g': > UnsatFun.g3: m > -UnsatFun.h: > -UnsatFun.h2: > -UnsatFun.h3: m > +UnsatFun.h: > +UnsatFun.h2: > +UnsatFun.h3: m > *** unexpected failure for UnsatFun(optasm) > > > I haven't any clue what this means. Is it bad? Is it good? Any > pointers? Unless the test case is bogus (which is possible, it was created by me, two years ago), the result ist bad. Here is the comment from the test case source file: Here we test how a partially applied function (f x) with a bottom result affects the strictness signature when used strictly (g) and lazily (g') In both cases, the parameter x should not be absent So it looks as if the strictness analysis become less powerful with your changes. Probably not downright wrong (I guess “L” is always correct), but less precise. I admit to not having documented the test case well enough back then. (I can dig deeper if required, but not right now.) Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
