There appears to be a codegen regression around GADTs in GHC 8.10-rc1 (also present on HEAD). Here’s a program that illustrates the issue:

{-# OPTIONS_GHC -O2 -ddump-stg #-}
{-# LANGUAGE GADTs #-}
module M1 where

data T a where
  C :: T ()

f :: (T () -> IO ()) -> IO ()
f g = g C >> g C

When compiling this on GHC 8.8.2, the STG output shows that both references to C are compiled to a single statically-allocated closure, as I would expect:

M1.$WC = CCS_DONT_CARE M1.C! [];

M1.f1 =
    \r [g_s1rK void_0E]
        case g_s1rK M1.$WC GHC.Prim.void# of {
          Unit# _ -> g_s1rK M1.$WC GHC.Prim.void#;
        };

But on GHC 8.10, things go wrong, and GHC allocates two entirely new closures on the heap!

M1.f1 =
    \r [g_sHU void_0E]
        let { sat_sHW = CCCS M1.C! [];
        } in
          case g_sHU sat_sHW GHC.Prim.void# of {
          Unit# _ ->
          let { sat_sI0 = CCCS M1.C! []; } in  g_sHU sat_sI0 GHC.Prim.void#;
          };

Examining the output of -ddump-cmm confirms that these really are two heap allocations:

       cIq: // global
           Hp = Hp + 16;
           if (Hp > HpLim) (likely: False) goto cIs; else goto cIr;
       cIs: // global
           HpAlloc = 16;
           goto cIp;
       cIp: // global
           R2 = _sHU::P64;
           R1 = M1.f1_closure;
           call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8;
       cIr: // global
           I64[Hp - 8] = M1.C_con_info;
           I64[Sp - 16] = cIl;
           R2 = Hp - 7;
           R1 = _sHU::P64;
           P64[Sp - 8] = _sHU::P64;
           Sp = Sp - 16;
           call stg_ap_pv_fast(R2,
                               R1) returns to cIl, args: 8, res: 8, upd: 8;
       cIl: // global
           Hp = Hp + 16;
           if (Hp > HpLim) (likely: False) goto cIv; else goto cIu;
       cIv: // global
           HpAlloc = 16;
           R1 = R1;
           call stg_gc_unpt_r1(R1) returns to cIl, args: 8, res: 8, upd: 8;
       cIu: // global
           I64[Hp - 8] = M1.C_con_info;
           R2 = Hp - 7;
           R1 = P64[Sp + 8];
           Sp = Sp + 16;
           call stg_ap_pv_fast(R2, R1) args: 8, res: 0, upd: 8;

But that’s absurd, since C is a constant! Compare that to the far superior output on GHC 8.8:

       c1se: // global
           I64[Sp - 16] = c1sa;
           _s1rM::P64 = R2;
           R2 = M1.$WC_closure+1;
           R1 = _s1rM::P64;
           P64[Sp - 8] = _s1rM::P64;
           Sp = Sp - 16;
           call stg_ap_pv_fast(R2,
                               R1) returns to c1sa, args: 8, res: 8, upd: 8;
       c1sa: // global
           R2 = M1.$WC_closure+1;
           R1 = P64[Sp + 8];
           Sp = Sp + 16;
           call stg_ap_pv_fast(R2, R1) args: 8, res: 0, upd: 8;

This change hits extensible effects libraries particularly hard, since those libraries often define GADTs like these:

data Reader r a where
  Ask :: Reader r r

data State s a where
  Get :: State s s
  Put :: s -> State s ()

It’s definitely unexpected that each use of Ask and Get would generate a separate heap allocation!