1. 23 Jan, 2017 1 commit
  2. 18 Jan, 2017 1 commit
  3. 15 Jan, 2017 1 commit
  4. 13 Jan, 2017 1 commit
    • Simon Peyton Jones's avatar
      Record evaluated-ness on workers and wrappers · 6b976eb8
      Simon Peyton Jones authored
      In Trac #13027, comment:20, I noticed that wrappers created after
      demand analysis weren't recording the evaluated-ness of strict
      constructor arguments.  In the ticket that led to a (debatable)
      Lint error but in general the more we know about evaluated-ness
      the better we can optimise.
      
      This commit adds that info both in the worker (on args) and in
      the wrapper (on CPR result patterns).
      
      See Note [Record evaluated-ness in worker/wrapper] in WwLib
      
      On the way I defined Id.setCaseBndrEvald, and used it to shorten
      the code in a few other places
      6b976eb8
  5. 17 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix shadowing in mkWwBodies · 692c8df0
      Simon Peyton Jones authored
      This bug, exposed by Trac #12562 was very obscure, and has been
      lurking for a long time.  What happened was that, in the
      worker/wrapper split
      
        a tyvar binder for a worker function
        accidentally shadowed an in-scope term variable
        that was mentioned in the body of the function
      
      It's jolly hard to provoke, so I have not even attempted to make
      a test case.  There's a Note [Freshen WW arguments] to explain.
      
      Interestingly, fixing the bug (which meant fresher type variables)
      revealed a second lurking bug: I'd failed to apply the substitution to
      the coercion in the second last case of mkWWArgs, which introduces a
      Cast.
      692c8df0
  6. 02 Sep, 2016 1 commit
    • Sergei Trofimovich's avatar
      extend '-fmax-worker-args' limit to specialiser (Trac #11565) · f93c363f
      Sergei Trofimovich authored
      It's a complementary change to
          a48de37d
          restore -fmax-worker-args handling (Trac #11565)
      
      I don't have a small example but I've noticed another
      discrepancy when was profiling GHC for performance
      
          cmmExprNative :: ReferenceKind -> CmmExpr -> CmmOptM CmmExpr
      
      was specialised by 'spec_one' down to a function with arity 159.
      As a result 'perf record' pointed at it as at slowest
      function in whole ghc library.
      
      I've extended -fmax-worker-args effect to 'spec_one'
      as it does the same worker/wrapper split to push
      arguments to the heap.
      
      The change decreases heap usage on a synth.bash benchmark
      (Trac #9221) from 67G down to 64G (-4%). Benchmark runtime
      decreased from 14.5 s down to 14.s (-7%).
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      
      Reviewers: ezyang, simonpj, austin, goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2507
      
      GHC Trac Issues: #11565
      f93c363f
  7. 01 Sep, 2016 1 commit
    • Sergei Trofimovich's avatar
      restore -fmax-worker-args handling (Trac #11565) · a48de37d
      Sergei Trofimovich authored
      maxWorkerArgs handling was accidentally lost 3 years ago
      in a major update of demand analysis
          commit 0831a12e
      
      Old regression is noticeable as:
      - code bloat (requires stack reshuffling)
      - compilation slowdown (more code to optimise/generate)
      - and increased heap usage (DynFlags unboxing/reboxing?)
      
      On a simple compile benchmark this change causes heap
      allocation drop from 70G don to 67G (ghc perf build).
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      
      Reviewers: simonpj, ezyang, goldfire, austin, bgamari
      
      Reviewed By: simonpj, ezyang
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2503
      
      GHC Trac Issues: #11565
      a48de37d
  8. 25 Aug, 2016 1 commit
  9. 21 Jul, 2016 1 commit
    • Ömer Sinan Ağacan's avatar
      Implement unboxed sum primitive type · 714bebff
      Ömer Sinan Ağacan authored
      Summary:
      This patch implements primitive unboxed sum types, as described in
      https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes.
      
      Main changes are:
      
      - Add new syntax for unboxed sums types, terms and patterns. Hidden
        behind `-XUnboxedSums`.
      
      - Add unlifted unboxed sum type constructors and data constructors,
        extend type and pattern checkers and desugarer.
      
      - Add new RuntimeRep for unboxed sums.
      
      - Extend unarise pass to translate unboxed sums to unboxed tuples right
        before code generation.
      
      - Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better
        code generation when sum values are involved.
      
      - Add user manual section for unboxed sums.
      
      Some other changes:
      
      - Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to
        `MultiValAlt` to be able to use those with both sums and tuples.
      
      - Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really
        wrong, given an `Any` `TyCon`, there's no way to tell what its kind
        is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`.
      
      - Fix some bugs on the way: #12375.
      
      Not included in this patch:
      
      - Update Haddock for new the new unboxed sum syntax.
      
      - `TemplateHaskell` support is left as future work.
      
      For reviewers:
      
      - Front-end code is mostly trivial and adapted from unboxed tuple code
        for type checking, pattern checking, renaming, desugaring etc.
      
      - Main translation routines are in `RepType` and `UnariseStg`.
        Documentation in `UnariseStg` should be enough for understanding
        what's going on.
      
      Credits:
      
      - Johan Tibell wrote the initial front-end and interface file
        extensions.
      
      - Simon Peyton Jones reviewed this patch many times, wrote some code,
        and helped with debugging.
      
      Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin,
                 simonmar, hvr, erikd
      
      Reviewed By: simonpj
      
      Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire,
                   thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2259
      714bebff
  10. 12 May, 2016 1 commit
  11. 12 Apr, 2016 1 commit
  12. 06 Apr, 2016 1 commit
    • Joachim Breitner's avatar
      Demand Analyzer: Do not set OneShot information (second try) · 0f58d348
      Joachim Breitner authored
      as suggested in ticket:11770#comment:1. This code was buggy
      (#11770), and the occurrence analyzer does the same job anyways.
      
      This also elaborates the notes in the occurrence analyzer accordingly.
      
      Previously, the worker/wrapper code would go through lengths to transfer
      the oneShot annotations from the original function to both the worker
      and the wrapper. We now simply transfer the demand on the worker, and
      let the subsequent occurrence analyzer push this onto the lambda
      binders.
      
      This also requires the occurrence analyzer to do this more reliably.
      Previously, it would not hand out OneShot annotatoins to things that
      would not `certainly_inline` (and it might not have mattered, as the
      Demand Analysis might have handed out the annotations). Now we hand out
      one-shot annotations unconditionally.
      
      Differential Revision: https://phabricator.haskell.org/D2085
      0f58d348
  13. 27 Jan, 2016 1 commit
  14. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
  15. 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
  16. 05 Aug, 2015 1 commit
  17. 21 Jul, 2015 1 commit
  18. 18 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · ffc21506
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      
      - Haddock needs to absorb the change too; so there is a submodule update
      ffc21506
  19. 14 May, 2015 1 commit
    • Austin Seipp's avatar
      Revert multiple commits · 3cf8ecdc
      Austin Seipp authored
      This reverts multiple commits from Simon:
      
        - 04a484ea Test Trac #10359
        - a9ccd37a Test Trac #10403
        - c0aae6f6 Test Trac #10248
        - eb6ca851 Make the "matchable-given" check happen first
        - ca173aa3 Add a case to checkValidTyCon
        - 51cbad15 Update haddock submodule
        - 6e1174da Separate transCloVarSet from fixVarSet
        - a8493e03 Fix imports in HscMain (stage2)
        - a154944b Two wibbles to fix the build
        - 5910a1bc Change in capitalisation of error msg
        - 130e93aa Refactor tuple constraints
        - 8da785d5 Delete commented-out line
      
      These break the build by causing Haddock to fail mysteriously when
      trying to examine GHC.Prim it seems.
      3cf8ecdc
  20. 13 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · 130e93aa
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      130e93aa
  21. 01 Dec, 2014 1 commit
  22. 04 Nov, 2014 1 commit
  23. 19 Sep, 2014 1 commit
  24. 28 Aug, 2014 1 commit
    • Simon Peyton Jones's avatar
      Make worker/wrapper work on INLINEABLE things · 9cf5906b
      Simon Peyton Jones authored
      This fixes a long-standing bug: Trac #6056.  The trouble was that
      INLINEABLE "used up" the unfolding for the Id, so it couldn't be
      worker/wrapper'd by the strictness analyser.
      
      This patch allows the w/w to go ahead, and makes the *worker* INLINEABLE
      instead, so it can later be specialised.
      
      However, that doesn't completely solve the problem, because the dictionary
      argument (which the specialiser treats specially) may be strict and
      hence unpacked by w/w, so now the worker won't be specilialised after all.
      
      Solution: never unpack dictionary arguments, which is done by the isClassTyCon
                test in WwLib.deepSplitProductType_maybe
      9cf5906b
  25. 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
  26. 24 Apr, 2014 1 commit
  27. 06 Mar, 2014 1 commit
    • Simon Peyton Jones's avatar
      Make the demand on a binder compatible with type (fixes Trac #8569) · 4b355cd2
      Simon Peyton Jones authored
      Because of GADTs and casts we were getting binders whose
      demand annotation was more deeply nested than made sense
      for its type.
      
      See Note [Trimming a demand to a type], in Demand.lhs,
      which I reproduce here:
      
         Note [Trimming a demand to a type]
         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         Consider this:
      
           f :: a -> Bool
           f x = case ... of
                   A g1 -> case (x |> g1) of (p,q) -> ...
                   B    -> error "urk"
      
         where A,B are the constructors of a GADT.  We'll get a U(U,U) demand
         on x from the A branch, but that's a stupid demand for x itself, which
         has type 'a'. Indeed we get ASSERTs going off (notably in
         splitUseProdDmd, Trac #8569).
      
         Bottom line: we really don't want to have a binder whose demand is more
         deeply-nested than its type.  There are various ways to tackle this.
         When processing (x |> g1), we could "trim" the incoming demand U(U,U)
         to match x's type.  But I'm currently doing so just at the moment when
         we pin a demand on a binder, in DmdAnal.findBndrDmd.
      4b355cd2
  28. 07 Feb, 2014 1 commit
    • Joachim Breitner's avatar
      In deepSplitCprType_maybe, be more forgiving · 312686c1
      Joachim Breitner authored
      the ConTag may be out of range (e.g. if the type constructor is imported
      via SOURCE and we don't know any of its data constructors); just return
      Nothing without complaining in that case. This fixes #8743.
      312686c1
  29. 20 Jan, 2014 1 commit
  30. 16 Jan, 2014 2 commits
    • Krzysztof Gogolewski's avatar
      Typos in comments · 98db754a
      Krzysztof Gogolewski authored
      98db754a
    • Joachim Breitner's avatar
      Refactor WorkWrap, get rid of worthSplittingArgDmd · 7cdf141d
      Joachim Breitner authored
      Instead of first checking whether splitting is useful, and then firing
      up the worker-wrapper-machinery, which will do the same checks again, we
      now simply generate a worker and wrapper, and while doing so keep track
      of whether what we did was in any way useful.
      
      So now there is only one place left where we decide whether we want to
      do w/w, and that place has access to more information, in particular the
      actual types at hand.
      7cdf141d
  31. 16 Dec, 2013 1 commit
  32. 12 Dec, 2013 1 commit
    • Simon Peyton Jones's avatar
      Improve the handling of used-once stuff · 80989de9
      Simon Peyton Jones authored
      Joachim and I are committing this onto a branch so that we can share it,
      but we expect to do a bit more work before merging it onto head.
      
      Nofib staus:
        - Most programs, no change
        - A few improve
        - A couple get worse (cacheprof, tak, rfib)
      Investigating the "get worse" set is what's holding up putting this
      on head.
      
      The major issue is this.  Consider
      
          map (f g) ys
      
      where f's demand signature looks like
      
         f :: <L,C1(C1(U))> -> <L,U> -> .
      
      So 'f' is not saturated.  What demand do we place on g?
      Answer
              C(C1(U))
      That is, the inner C1 should stay, even though f is not saturated.
      
      I found that this made a significant difference in the demand signatures
      inferred in GHC.IO, which uses lots of higher-order exception handlers.
      
      I also had to add used-once demand signatures for some of the
      'catch' primops, so that we know their handlers are only called once.
      80989de9
  33. 22 Nov, 2013 1 commit
    • Simon Peyton Jones's avatar
      Replace (State# RealWorld) with Void# where we just want a 0-bit value · f4384647
      Simon Peyton Jones authored
      We were re-using the super-magical "state token" type (which has
      VoidRep and is zero bits wide) for situations in which we simply want
      to lambda-abstract over a zero-bit argument. For example, join points:
      
         case (case x of { True -> e1; False -> e2 }) of
            Red  -> f1
            Blue -> True
      
      ==>
      
        let $j1 = \voidArg::Void# -> f1
        in
        case x of
          True -> case e1 of
                    Red -> $j1 void
                    Blue -> True
          False -> case e2 of
                    Red -> $j1 void
                    Blue -> True
      
      This patch introduces
      
         * The new primitive type GHC.Prim.Void#, with PrimRep = VoidRep
      
         * A new global Id GHC.Prim.voidPrimId :: Void#.
           This has no binding because the code generator drops it,
           but is used as an argument (eg in the call of $j1)
      
         * A new local Id, MkId.voidArgId, which can be lambda-bound
           when you need to lambda-abstract over it.
      
      and uses them throughout.
      
      Now the State# thing is used only when we need state!
      f4384647
  34. 12 Nov, 2013 1 commit
  35. 08 Nov, 2013 1 commit
  36. 24 Oct, 2013 2 commits
  37. 05 Oct, 2013 1 commit
  38. 01 Oct, 2013 1 commit