1. 07 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Make demand analysis understand catch · 9915b656
      Simon Peyton Jones authored
      As Trac #11222, and #10712 note, the strictness analyser
      needs to be rather careful about exceptions.  Previously
      it treated them as identical to divergence, but that
      won't quite do.
      
      See Note [Exceptions and strictness] in Demand, which
      explains the deal.
      
      Getting more strictness in 'catch' and friends is a
      very good thing.  Here is the nofib summary, keeping
      only the big ones.
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
                fasta          -0.1%     -6.9%     -3.0%     -3.0%     +0.0%
                  hpg          -0.1%     -2.0%     -6.2%     -6.2%     +0.0%
             maillist          -0.1%     -0.3%      0.08      0.09     +1.2%
      reverse-complem          -0.1%    -10.9%     -6.0%     -5.9%     +0.0%
               sphere          -0.1%     -4.3%      0.08      0.08     +0.0%
                 x2n1          -0.1%     -0.0%      0.00      0.00     +0.0%
      --------------------------------------------------------------------------------
                  Min          -0.2%    -10.9%    -17.4%    -17.3%     +0.0%
                  Max          -0.0%     +0.0%     +4.3%     +4.4%     +1.2%
       Geometric Mean          -0.1%     -0.3%     -2.9%     -3.0%     +0.0%
      
      On the way I did quite a bit of refactoring in Demand.hs
      9915b656
  2. 31 Dec, 2015 2 commits
  3. 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
         features.
      
       * 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.
      67465497
  4. 02 Dec, 2015 1 commit
  5. 30 Oct, 2015 1 commit
  6. 17 Oct, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Make Monad/Applicative instances MRP-friendly · e8ed2136
      Herbert Valerio Riedel authored
      This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e.
      such that the explicit definitions for `return` and `(>>)` match the
      MRP-style default-implementation, i.e.
      
        return = pure
      
      and
      
        (>>) = (*>)
      
      This way, e.g. all `return = pure` definitions can easily be grepped and
      removed in GHC 8.1;
      
      Test Plan: Harbormaster
      
      Reviewers: goldfire, alanz, bgamari, quchen, austin
      
      Reviewed By: quchen, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1312
      e8ed2136
  7. 26 Jul, 2015 1 commit
  8. 01 Jun, 2015 1 commit
    • Alan Zimmerman's avatar
      ApiAnnotations : strings in warnings do not return SourceText · e6191d1c
      Alan Zimmerman authored
      Summary:
      The strings used in a WARNING pragma are captured via
      
          strings :: { Located ([AddAnn],[Located FastString]) }
              : STRING { sL1 $1 ([],[L (gl $1) (getSTRING $1)]) }
          ..
      
      The STRING token has a method getSTRINGs that returns the original
      source text for a string.
      
      A warning of the form
      
          {-# WARNING Logic
                    , mkSolver
                    , mkSimpleSolver
                    , mkSolverForLogic
                    , solverSetParams
                    , solverPush
                    , solverPop
                    , solverReset
                    , solverGetNumScopes
                    , solverAssertCnstr
                    , solverAssertAndTrack
                    , solverCheck
                    , solverCheckAndGetModel
                    , solverGetReasonUnknown
                    "New Z3 API support is still incomplete and fragile: \
                    \you may experience segmentation faults!"
            #-}
      
      returns the concatenated warning string rather than the original source.
      
      This patch now deals with all remaining instances of getSTRING to bring
      in a SourceText for each.
      
      This updates the haddock submodule as well, for the AST change.
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin, goldfire
      
      Reviewed By: austin
      
      Subscribers: bgamari, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D907
      
      GHC Trac Issues: #10313
      e6191d1c
  9. 10 Feb, 2015 1 commit
  10. 16 Dec, 2014 2 commits
    • Peter Wortmann's avatar
      Source notes (CorePrep and Stg support) · 4cdbf802
      Peter Wortmann authored
      This is basically just about continuing maintaining source notes after
      the Core stage. Unfortunately, this is more involved as it might seem,
      as there are more restrictions on where ticks are allowed to show up.
      
      Notes:
      
      * We replace the StgTick / StgSCC constructors with a unified StgTick
        that can carry any tickish.
      
      * For handling constructor or lambda applications, we generally float
        ticks out.
      
      * Note that thanks to the NonLam placement, we know that source notes
        can never appear on lambdas. This means that as long as we are
        careful to always use mkTick, we will never violate CorePrep
        invariants.
      
      * This is however not automatically true for eta expansion, which
        needs to somewhat awkwardly strip, then re-tick the expression in
        question.
      
      * Where CorePrep floats out lets, we make sure to wrap them in the
        same spirit as FloatOut.
      
      * Detecting selector thunks becomes a bit more involved, as we can run
        into ticks at multiple points.
      
      (From Phabricator D169)
      4cdbf802
    • Peter Wortmann's avatar
      Source notes (Core support) · 993975d3
      Peter Wortmann authored
      This patch introduces "SourceNote" tickishs that link Core to the
      source code that generated it. The idea is to retain these source code
      links throughout code transformations so we can eventually relate
      object code all the way back to the original source (which we can,
      say, encode as DWARF information to allow debugging).  We generate
      these SourceNotes like other tickshs in the desugaring phase. The
      activating command line flag is "-g", consistent with the flag other
      compilers use to decide DWARF generation.
      
      Keeping ticks from getting into the way of Core transformations is
      tricky, but doable. The changes in this patch produce identical Core
      in all cases I tested -- which at this point is GHC, all libraries and
      nofib. Also note that this pass creates *lots* of tick nodes, which we
      reduce somewhat by removing duplicated and overlapping source
      ticks. This will still cause significant Tick "clumps" - a possible
      future optimization could be to make Tick carry a list of Tickishs
      instead of one at a time.
      
      (From Phabricator D169)
      993975d3
  11. 03 Dec, 2014 1 commit
  12. 20 Nov, 2014 1 commit
    • Jan Stolarek's avatar
      Split SynTyCon to SynonymTyCon and FamilyTyCon · 696fc4ba
      Jan Stolarek authored
      This patch refactors internal representation of type synonyms and type families by splitting them into two separate data constructors of TyCon data type. The main motivation is is that some fields make sense only for type synonyms and some make sense only for type families. This will be even more true with the upcoming injective type families.
      
      There is also some refactoring of names to keep the naming constistent. And thus tc_kind field has become tyConKind and tc_roles has become tcRoles. Both changes are not visible from the outside of TyCon module.
      
      Updates haddock submodule
      
      Reviewers: simonpj
      
      Differential Revision: https://phabricator.haskell.org/D508
      
      GHC Trac Issues: #9812
      696fc4ba
  13. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      Summary:
      This includes pretty much all the changes needed to make `Applicative`
      a superclass of `Monad` finally. There's mostly reshuffling in the
      interests of avoid orphans and boot files, but luckily we can resolve
      all of them, pretty much. The only catch was that
      Alternative/MonadPlus also had to go into Prelude to avoid this.
      
      As a result, we must update the hsc2hs and haddock submodules.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan: Build things, they might not explode horribly.
      
      Reviewers: hvr, simonmar
      
      Subscribers: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D13
      d94de872
  14. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  15. 13 Feb, 2014 1 commit
  16. 26 Jan, 2014 1 commit
  17. 18 Oct, 2013 1 commit
  18. 11 Sep, 2013 1 commit
  19. 16 Aug, 2013 2 commits
    • Jan Stolarek's avatar
      Comments only · 82d5aa03
      Jan Stolarek authored
      I restored part of documentation that describes what is a let-no-escape
      and which was deleted 10 months ago together with the old codegen. Then
      I removed lots of Literate Haskell clutter (like empty \begin{code} -
      \end{code} blocks) and finally decided to remove all the Literate Haskell
      markup because there wasn't much of it left, but it made comments so
      difficult to read.
      82d5aa03
    • Jan Stolarek's avatar
      Comments only · ec621f3c
      Jan Stolarek authored
      ec621f3c
  20. 19 Jun, 2013 1 commit
  21. 06 Jun, 2013 1 commit
    • Simon Peyton Jones's avatar
      Implement cardinality analysis · 99d4e5b4
      Simon Peyton Jones authored
      This major patch implements the cardinality analysis described
      in our paper "Higher order cardinality analysis". It is joint
      work with Ilya Sergey and Dimitrios Vytiniotis.
      
      The basic is augment the absence-analysis part of the demand
      analyser so that it can tell when something is used
      	 never
      	 at most once
       	 some other way
      
      The "at most once" information is used
          a) to enable transformations, and
             in particular to identify one-shot lambdas
          b) to allow updates on thunks to be omitted.
      
      There are two new flags, mainly there so you can do performance
      comparisons:
          -fkill-absence   stops GHC doing absence analysis at all
          -fkill-one-shot  stops GHC spotting one-shot lambdas
                           and single-entry thunks
      
      The big changes are:
      
      * The Demand type is substantially refactored.  In particular
        the UseDmd is factored as follows
            data UseDmd
              = UCall Count UseDmd
              | UProd [MaybeUsed]
              | UHead
              | Used
      
            data MaybeUsed = Abs | Use Count UseDmd
      
            data Count = One | Many
      
        Notice that UCall recurses straight to UseDmd, whereas
        UProd goes via MaybeUsed.
      
        The "Count" embodies the "at most once" or "many" idea.
      
      * The demand analyser itself was refactored a lot
      
      * The previously ad-hoc stuff in the occurrence analyser for foldr and
        build goes away entirely.  Before if we had build (\cn -> ...x... )
        then the "\cn" was hackily made one-shot (by spotting 'build' as
        special.  That's essential to allow x to be inlined.  Now the
        occurrence analyser propagates info gotten from 'build's stricness
        signature (so build isn't special); and that strictness sig is
        in turn derived entirely automatically.  Much nicer!
      
      * The ticky stuff is improved to count single-entry thunks separately.
      
      One shortcoming is that there is no DEBUG way to spot if an
      allegedly-single-entry thunk is acually entered more than once.  It
      would not be hard to generate a bit of code to check for this, and it
      would be reassuring.  But it's fiddly and I have not done it.
      
      Despite all this fuss, the performance numbers are rather under-whelming.
      See the paper for more discussion.
      
             nucleic2          -0.8%    -10.9%      0.10      0.10     +0.0%
               sphere          -0.7%     -1.5%      0.08      0.08     +0.0%
      --------------------------------------------------------------------------------
                  Min          -4.7%    -10.9%     -9.3%     -9.3%    -50.0%
                  Max          -0.4%     +0.5%     +2.2%     +2.3%     +7.4%
       Geometric Mean          -0.8%     -0.2%     -1.3%     -1.3%     -1.8%
      
      I don't quite know how much credence to place in the runtime changes,
      but movement seems generally in the right direction.
      99d4e5b4
  22. 14 May, 2013 1 commit
    • ian@well-typed.com's avatar
      Fix the GHC package DLL-splitting · 60b86b04
      ian@well-typed.com authored
      There's now an internal -dll-split flag, which we use to tell GHC how
      the GHC package is split into 2 separate DLLs. This is used by
      Packages.isDllName to determine whether a call is within the same
      DLL, or whether it is a call to another DLL.
      60b86b04
  23. 06 Apr, 2013 1 commit
  24. 27 Feb, 2013 1 commit
  25. 02 Feb, 2013 1 commit
  26. 30 Jan, 2013 1 commit
  27. 16 Oct, 2012 1 commit
    • ian@well-typed.com's avatar
      Some alpha renaming · cd33eefd
      ian@well-typed.com authored
      Mostly d -> g (matching DynFlag -> GeneralFlag).
      Also renamed if* to when*, matching the Haskell if/when names
      cd33eefd
  28. 25 Sep, 2012 1 commit
  29. 18 Sep, 2012 2 commits
    • Simon Peyton Jones's avatar
      Undo making Any into a type family, for now · 1b5c8337
      Simon Peyton Jones authored
      Making Any a type family is the right thing to do, but it messes up
      the proxy kind arguments in TypeLits and Singletons, so I'm backing it
      out for now.
      
      More thought required!
      1b5c8337
    • Simon Peyton Jones's avatar
      Make a start towards eta-rules and injective families · 58470fb7
      Simon Peyton Jones authored
      * Make Any into a type family (which it should always have been)
        This is to support the future introduction of eta rules for
        product types (see email on ghc-users title "PolyKind issue"
        early Sept 2012)
      
      * Add the *internal* data type support for
          (a) closed type families [so that you can't give
              type instance for 'Any']
          (b) injective type families [because Any is really
              injective]
        This amounts to two boolean flags on the SynFamilyTyCon
        constructor of TyCon.SynTyConRhs.
      
      There is some knock-on effect, but all of a routine nature.
      
      It remains to offer source syntax for either closed or
      injective families.
      58470fb7
  30. 15 Sep, 2012 1 commit
    • Simon Peyton Jones's avatar
      Fix Trac #7237; mixup with empty tuples · 84bb8541
      Simon Peyton Jones authored
      When converting from Core to STG, we swith pattern matching on
      on a *nullary* unboxed tuple into matching using a PrimAlt on RealWorld#
         case e (RealWorld#) of { DEFAULT -> ... }
      This semms messy to me, but it works.  There was a bug in that we were
      changing to PrimAlt, but not using a DEFAULT AltCon.
      84bb8541
  31. 03 Sep, 2012 1 commit
  32. 05 Aug, 2012 1 commit
  33. 24 Jul, 2012 1 commit
  34. 22 Jun, 2012 1 commit
  35. 05 Jun, 2012 1 commit
  36. 15 May, 2012 1 commit
    • batterseapower's avatar
      Support code generation for unboxed-tuple function arguments · 09987de4
      batterseapower authored
      This is done by a 'unarisation' pre-pass at the STG level which
      translates away all (live) binders binding something of unboxed
      tuple type.
      
      This has the following knock-on effects:
        * The subkind hierarchy is vastly simplified (no UbxTupleKind or ArgKind)
        * Various relaxed type checks in typechecker, 'foreign import prim' etc
        * All case binders may be live at the Core level
      09987de4