1. 17 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      No join-point from an INLINE function with wrong arity · a7dbafe9
      Simon Peyton Jones authored
      The main payload of this patch is NOT to make a join-point
      from a function with an INLINE pragma and the wrong arity;
      see Note [Join points and INLINE pragmas] in CoreOpt.
      This is what caused Trac #13413.
      But we must do the exact same thing in simpleOptExpr,
      which drove me to the following refactoring:
      * Move simpleOptExpr and simpleOptPgm from CoreSubst to a new
        module CoreOpt along with a few others (exprIsConApp_maybe,
        pushCoArg, etc)
        This eliminates a module loop altogether (delete
        CoreArity.hs-boot), and stops CoreSubst getting too huge.
      * Rename Simplify.matchOrConvertToJoinPoint
           to joinPointBinding_maybe
        Move it to the new CoreOpt
        Use it in simpleOptExpr as well as in Simplify
      * Define CoreArity.joinRhsArity and use it
  2. 18 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      (Another) minor refactoring of substitutions · b5292557
      Simon Peyton Jones authored
      No change in functionality here, but greater clarity:
      * In FamInstEnv.FlattenEnv, kill off the fi_in_scope field
        We are already maintaining an in-scope set in the fe_subst field,
        so it's silly do to it twice.
        (This isn't strictly connected to the rest of this patch, but
        the nomenclature changes below affect the same code, so I put
        them together.)
      * TyCoRep.extendTCVSubst used to take a TyVar or a CoVar and work
        out what to do, but in fact we almost always know which of the
        two we are doing.  So:
          - define extendTvSubst, extendCvSubst
          - and use them
      * Similar renamings in TyCoRep:
         - extendTCvSubstList        -->   extendTvSubstList
         - extendTCvSubstBinder      -->   extendTvSubstBinder
         - extendTCvSubstAndInScope  --> extendTvSubstAndInScope
      * Add Type.extendTvSubstWithClone, extendCvSubstWithClone
      * Similar nomenclature changes in Subst, SimplEnv, Specialise
      * Kill off TyCoRep.substTelescope (never used)
  3. 17 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      (Some of this code is derived from GHCJS.)
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      Reaosns we want this:
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      Things that are not currently implemented for -fexternal-interpreter:
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1562
  4. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
       * The type of `*` is now `*`. No more `BOX`.
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
       * The new extension `TypeInType` turns on the new user-facing
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
       * The new features are still quite experimental and may be in flux.
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
       * TODO: Update user manual.
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
  5. 21 Aug, 2015 1 commit
    • thomie's avatar
      Refactor: delete most of the module FastTypes · 2f29ebbb
      thomie authored
      This reverses some of the work done in #1405, and goes back to the
      assumption that the bootstrap compiler understands GHC-haskell.
      In particular:
        * use MagicHash instead of _ILIT and _CLIT
        * pattern matching on I# if possible, instead of using iUnbox
        * use Int#/Char#/Addr# instead of the following type synonyms:
          - type FastInt   = Int#
          - type FastChar  = Char#
          - type FastPtr a = Addr#
        * inline the following functions:
          - iBox           = I#
          - cBox           = C#
          - fastChr        = chr#
          - fastOrd        = ord#
          - eqFastChar     = eqChar#
          - shiftLFastInt  = uncheckedIShiftL#
          - shiftR_FastInt = uncheckedIShiftRL#
          - shiftRLFastInt = uncheckedIShiftRL#
        * delete the following unused functions:
          - minFastInt
          - maxFastInt
          - uncheckedIShiftRA#
          - castFastPtr
          - panicDocFastInt and pprPanicFastInt
        * rename panicFastInt back to panic#
      These functions remain, since they actually do something:
        * iUnbox
        * bitAndFastInt
        * bitOrFastInt
      Test Plan: validate
      Reviewers: austin, bgamari
      Subscribers: rwbarton
      Differential Revision: https://phabricator.haskell.org/D1141
      GHC Trac Issues: #1405
  6. 20 Nov, 2014 1 commit
  7. 16 Jun, 2011 1 commit
    • Simon Peyton Jones's avatar
      Add dynamically-linked plugins (see Trac #3843) · 592def09
      Simon Peyton Jones authored
      This patch was originally developed by Max Bolingbroke, and worked on
      further by Austin Seipp.  It allows you to write a Core-to-Core pass
      and have it dynamically linked into an otherwise-unmodified GHC, and
      run at a place you specify in the Core optimisation pipeline.
      Main components:
        - CoreMonad: new types Plugin, PluginPass
                     plus a new constructor CoreDoPluginPass in CoreToDo
        - SimplCore: stuff to dynamically load any plugins, splice
          them into the core-to-core pipeline, and invoke them
        - Move "getCoreToDo :: DynFlags -> [CoreToDo]"
            which constructs the main core-to-core pipeline
            from CoreMonad to SimplCore
          SimplCore is the driver for the optimisation pipeline, and it
          makes more sense to have the pipeline construction in the driver
          not in the infrastructure module.
        - New module DynamicLoading: invoked by SimplCore to load any plugins
          Some consequential changes in Linker.
        - New module GhcPlugins: this should be imported by plugin modules; it
          it not used by GHC itself.