• Ben Gamari's avatar
    Generate Typeable info at definition sites · bef2f03e
    Ben Gamari authored
    This patch implements the idea floated in Trac #9858, namely that we
    should generate type-representation information at the data type
    declaration site, rather than when solving a Typeable constraint.
    
    However, this turned out quite a bit harder than I expected. I still
    think it's the right thing to do, and it's done now, but it was quite
    a struggle.
    
    See particularly
    
     * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
     * Note [The overall promotion story] in DataCon (clarifies existing stuff)
    
    The most painful bit was that to generate Typeable instances (ie
    TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
    etc:
    
     * We need to have enough data types around to *define* a TyCon
     * Many of these types are wired-in
    
    Also, to minimise the code generated for each data type, I wanted to
    generate pure data, not CAFs with unpackCString# stuff floating about.
    
    Performance
    ~~~~~~~~~~~
    Three perf/compiler tests start to allocate quite a bit more. This isn't
    surprising, because they all allocate zillions of data types, with
    practically no other code, esp. T1969
    
     * T3294:   GHC allocates 110% more (filed #11030 to track this)
     * T1969:   GHC allocates 30% more
     * T4801:   GHC allocates 14% more
     * T5321FD: GHC allocates 13% more
     * T783:    GHC allocates 12% more
     * T9675:   GHC allocates 12% more
     * T5642:   GHC allocates 10% more
     * T9961:   GHC allocates 6% more
    
     * T9203:   Program allocates 54% less
    
    I'm treating this as acceptable. The payoff comes in Typeable-heavy
    code.
    
    Remaining to do
    ~~~~~~~~~~~~~~~
    
     * I think that "TyCon" and "Module" are over-generic names to use for
       the runtime type representations used in GHC.Typeable. Better might be
       "TrTyCon" and "TrModule". But I have not yet done this
    
     * Add more info the the "TyCon" e.g. source location where it was
       defined
    
     * Use the new "Module" type to help with Trac Trac #10068
    
     * It would be possible to generate TyConRepName (ie Typeable
       instances) selectively rather than all the time. We'd need to persist
       the information in interface files. Lacking a motivating reason I have
       not done this, but it would not be difficult.
    
    Refactoring
    ~~~~~~~~~~~
    As is so often the case, I ended up refactoring more than I intended.
    In particular
    
     * In TyCon, a type *family* (whether type or data) is repesented by a
       FamilyTyCon
         * a algebraic data type (including data/newtype instances) is
           represented by AlgTyCon This wasn't true before; a data family
           was represented as an AlgTyCon. There are some corresponding
           changes in IfaceSyn.
    
         * Also get rid of the (unhelpfully named) tyConParent.
    
     * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
       optionally promoted; and use it elsewhere in GHC.
    
     * Cleanup handling of knownKeyNames
    
     * Each TyCon, including promoted TyCons, contains its TyConRepName, if
       it has one. This is, in effect, the name of its Typeable instance.
    
    Requires update of the haddock submodule.
    
    Differential Revision: https://phabricator.haskell.org/D757
    bef2f03e
all.T 15.3 KB