However, looking at the pass order in `SimplCore`, specialisation runs very early before any major simplification but SpecConstr runs very late right at the end of the pipeline. Does anyone know the justification for this?
Here’s my thought * Typeclass specialisation makes a specialised copy of a function in which many higher order calls (via the dictionary) are replaced with calls to known functions. That exposes LOTS of stuff to all phases of optimisation including the strictness analyser. So running it early is good. * Moreover typeclass specialisation is exposed simply by type at which we call an overloaded function, and that is apparent early. So running it early is OK. * SpecConstr just eliminates data constructor allocation and case expressions, so it is less likely to unleash a cascade of further optimisations. * Moreover, SpecConstr only works when we have f (a:b), and calls like that are more likely to be exposed after we’ve optimised the program. So do it late. All of these things are doubtless only sort-of-true. Concrete examples to the contrary would be useful. Simon -----Original Message----- From: ghc-devs [mailto:[email protected]] On Behalf Of Joachim Breitner Sent: 20 March 2018 13:42 To: [email protected] Subject: Re: Why does SpecConstr run far later than specialisation Hi, Am Dienstag, den 20.03.2018, 13:23 +0000 schrieb Matthew Pickering: > As far as I understand it, the goals of SpecConstr and specialisation > are the same. One works for normal value arguments and one works for > special type class dictionary arguments. > > However, looking at the pass order in `SimplCore`, specialisation runs > very early before any major simplification but SpecConstr runs very > late right at the end of the pipeline. > > Does anyone know the justification for this? It seems intuitively that > they should work in the same way. Just a guess: We want the demand analyzer to run before SpecConstr, because I expect that there are many functions where both the demand analyzer are happy to do something, and SpecConstr is happy to do something, but the worker-wrapper done by DmdAnal is strictly preferable (no code duplication, for example.) But the Specializer and the demand analyzer have no overlap, and we we do want to strictness-analyzer the type-class-specialized code. But as I said, it’s just a guess. Cheers, Joachim -- Joachim “nomeata” Breitner [email protected] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cff102ef484bd411807e108d58e68796c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636571501747132026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=R1t%2FW5BJeJPausEfMIfbYOgwj5qLaX5Hda4Z4LwDoJk%3D&reserved=0
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
