
Ccing ghc devs since that’s a better forum perhaps
Crazy theory:
this is a regression due the the partial changes to pattern matching
coverage checking in 8.10 that finished / landed in ghc 9
Why:
Desugaring is when pattern/ case statement translation happens I think?
And the only obvious “big thing” is that you have some huge , albeit sane
for a compiler, pattern matching
I’d first check if the new ghc 9 release doesn’t have that regression in
build time that you experienced. And if it does file a ticket.
I may be totally wrong, but that seems like a decent likelihood !
On Mon, Feb 15, 2021 at 12:20 PM Troels Henriksen
Carter Schonwald
writes: How big are your data types in the file In question? Do you ghc generics or deriving or template Haskell? Could you share a link to the file in question ?
The file does not define any large data types itself, but it operates on some fairly large data types (an AST, it's a compiler). But so do many other modules that work just fine. It uses no generics, nontrivial deriving, or Template Haskell. It's this file:
https://github.com/diku-dk/futhark/blob/master/src/Futhark/Pass/ExtractKerne...
I also found a handful of other modules in my project that are significantly slower to compile in GHC 8.10, and seemingly also because of the desugarer, but none of them have any obvious smoking guns like generics or TH.
The only commonality I can find is that the affected modules contain functions with a relatively large typeclass context. I use ConstraintKinds to make them more concise, and I guess unfolded there may be 30-40 equality/class constraints in total. Like this:
type DistLore lore = ( Bindable lore, HasSegOp lore, BinderOps lore, LetDec lore ~ Type, ExpDec lore ~ (), BodyDec lore ~ () )
where the 'Bindable' constraint in particular then implies a further handful of "~" constraints:
class ( ASTLore lore, FParamInfo lore ~ DeclType, LParamInfo lore ~ Type, RetType lore ~ DeclExtType, BranchType lore ~ ExtType, SetType (LetDec lore) ) => Bindable lore where ...
FParamInfo/LParamInfo/etc are type families. Are such constraints particularly slow?
-- \ Troels /\ Henriksen