<div dir="auto">Ccing ghc devs since that’s a better forum perhaps </div><div dir="auto">Crazy theory: </div><div dir="auto"><br></div><div dir="auto">this is a regression due the the partial changes to pattern matching coverage checking in 8.10 that finished / landed in ghc 9</div><div dir="auto"><br></div><div dir="auto">Why: </div><div dir="auto">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 </div><div dir="auto"><br></div><div dir="auto">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.  </div><div dir="auto"><br></div><div dir="auto">I may be totally wrong, but that seems like a decent likelihood !</div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 15, 2021 at 12:20 PM Troels Henriksen <<a href="mailto:athas@sigkill.dk">athas@sigkill.dk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> writes:<br>
<br>
> How big are your data types in the file In question? Do you ghc generics or<br>
> deriving or template Haskell? Could you share a link to the file in<br>
> question ?<br>
<br>
The file does not define any large data types itself, but it operates on<br>
some fairly large data types (an AST, it's a compiler).  But so do many<br>
other modules that work just fine.  It uses no generics, nontrivial<br>
deriving, or Template Haskell.  It's this file:<br>
<a href="https://github.com/diku-dk/futhark/blob/master/src/Futhark/Pass/ExtractKernels/DistributeNests.hs" rel="noreferrer" target="_blank">https://github.com/diku-dk/futhark/blob/master/src/Futhark/Pass/ExtractKernels/DistributeNests.hs</a><br>
<br>
I also found a handful of other modules in my project that are<br>
significantly slower to compile in GHC 8.10, and seemingly also because<br>
of the desugarer, but none of them have any obvious smoking guns like<br>
generics or TH.<br>
<br>
The only commonality I can find is that the affected modules contain<br>
functions with a relatively large typeclass context.  I use<br>
ConstraintKinds to make them more concise, and I guess unfolded there<br>
may be 30-40 equality/class constraints in total.  Like this:<br>
<br>
    type DistLore lore =<br>
      ( Bindable lore,<br>
        HasSegOp lore,<br>
        BinderOps lore,<br>
        LetDec lore ~ Type,<br>
        ExpDec lore ~ (),<br>
        BodyDec lore ~ ()<br>
      )<br>
<br>
where the 'Bindable' constraint in particular then implies a further<br>
handful of "~" constraints:<br>
<br>
    class<br>
      ( ASTLore lore,<br>
        FParamInfo lore ~ DeclType,<br>
        LParamInfo lore ~ Type,<br>
        RetType lore ~ DeclExtType,<br>
        BranchType lore ~ ExtType,<br>
        SetType (LetDec lore)<br>
      ) =><br>
      Bindable lore<br>
      where<br>
      ...<br>
<br>
FParamInfo/LParamInfo/etc are type families.  Are such constraints<br>
particularly slow?<br>
<br>
-- <br>
\  Troels<br>
/\ Henriksen<br>
</blockquote></div></div>