1. 29 Oct, 2018 1 commit
    • Tobias Dammers's avatar
      Finish fix for #14880. · 5e45ad10
      Tobias Dammers authored
      The real change that fixes the ticket is described in
      Note [Naughty quantification candidates] in TcMType.
      Fixing this required reworking candidateQTyVarsOfType, the function
      that extracts free variables as candidates for quantification.
      One consequence is that we now must be more careful when quantifying:
      any skolems around must be quantified manually, and quantifyTyVars
      will now only quantify over metavariables. This makes good sense,
      as skolems are generally user-written and are listed in the AST.
      As a bonus, we now have more control over the ordering of such
      Along the way, this commit fixes #15711 and refines the fix
      to #14552 (by accepted a program that was previously rejected,
      as we can now accept that program by zapping variables to Any).
      This commit also does a fair amount of rejiggering kind inference
      of datatypes. Notably, we now can skip the generalization step
      in kcTyClGroup for types with CUSKs, because we get the
      kind right the first time. This commit also thus fixes #15743 and
       #15592, which both concern datatype kind generalisation.
      (#15591 is also very relevant.) For this aspect of the commit, see
      Note [Required, Specified, and Inferred in types] in TcTyClsDecls.
      Test cases: dependent/should_fail/T14880{,-2},
  2. 21 Aug, 2018 1 commit
    • Simon Peyton Jones's avatar
      Set strictness correctly for JoinIds · ce6ce788
      Simon Peyton Jones authored
      We were failing to keep correct strictness info when eta-expanding
      join points; Trac #15517.   The situation was something like
        \q v eta ->
           let j x = error "blah
               -- STR Lx   bottoming!
           in case y of
                 A -> j x eta
                 B -> blah
                 C -> j x eta
      So we spot j as a join point and eta-expand it.  But we must
      also adjust the stricness info, else it vlaimes to bottom after
      one arg is applied but now it has become two.
      I fixed this in two places:
       - In CoreOpt.joinPointBinding_maybe, adjust strictness info
       - In SimplUtils.tryEtaExpandRhs, return consistent values
         for arity and bottom-ness
  3. 25 Jul, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix PrelRules.caseRules to account for out-of-range tags · 9897f678
      Simon Peyton Jones authored
      As Trac #15436 points out, it is possible to get
         case dataToTag# (x :: T) of
            DEFAULT -> blah1
            -1#     -> blah2
            0       -> blah3
      The (-1#) alterantive is unreachable, because dataToTag# returns
      tags in the range [0..n-1] where n is the number of data constructors
      in type T.
      This actually made GHC crash; now we simply discard the unreachable
      alterantive.  See Note [Unreachable caseRules alternatives]
      in PrelRules
  4. 18 Jun, 2018 1 commit
  5. 23 May, 2018 1 commit
    • Simon Peyton Jones's avatar
      Don't expose strictness when sm_inline is False · d191db48
      Simon Peyton Jones authored
      This is very much a corner case, but Trac #15163 showed
      that if you have a RULE like
          forall x. f (g x) = ..x..
      and g = undefined, then the simplifier is likely to discard
      that 'x' argument. It is usually right to do so; but not here
      because then x is used on the right but not bound on the left.
      The fix is a narrow one, aimed at this rather pathalogical case.
      See Note [Do not expose strictness if sm_inline=False] in
  6. 27 Apr, 2018 1 commit
  7. 09 Apr, 2018 1 commit
  8. 06 Apr, 2018 1 commit
  9. 07 Feb, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix utterly bogus TagToEnum rule in caseRules · 4aa98f4a
      Simon Peyton Jones authored
      In prelRules we had:
        tx_con_tte :: DynFlags -> AltCon -> AltCon
        tx_con_tte _      DEFAULT      = DEFAULT
        tx_con_tte dflags (DataAlt dc)
          | tag == 0  = DEFAULT   -- See Note [caseRules for tagToEnum]
          | otherwise = LitAlt (mkMachInt dflags (toInteger tag))
      The tag==0 case is totally wrong, and led directly to Trac #14768.
      See "Beware" in Note [caseRules for tagToEnum] (in the patch).
      Easily fixed, though!
  10. 09 Jan, 2018 1 commit
    • Simon Peyton Jones's avatar
      preInlineUnconditionally is ok for INLINEABLE · 1c1e46c1
      Simon Peyton Jones authored
      When debugging Trac #14650, I found a place where we had
          let {-# INLINEABLE f #-}
              f = BIG
          in f 7
      but 'f' wasn't getting inlined at its unique call site.
      There's a good reason for that with INLINE things, which
      should only inline when saturated, but not  for INILNEABLE
      This patch narrows the case where preInlineUnconditionally
      gives up.  It significantly shortens (and improves) the code
      for #14650.
  11. 21 Dec, 2017 1 commit
  12. 08 Dec, 2017 1 commit
  13. 08 Nov, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix in-scope set in simplifier · fe6848f5
      Simon Peyton Jones authored
      This patch fixes Trac #14408.  The problem was that the StaticEnv
      field of an ApplyToVar or Select continuation didn't have enough
      variables in scope.  The fix is simple, and I documented the
      invariant in Note [StaticEnv invariant] in SimplUtils.
      No change in behaviour: this just stops an ASSERT from tripping.
  14. 29 Oct, 2017 1 commit
    • Joachim Breitner's avatar
      Implement a dedicated exitfication pass #14152 · 0e953da1
      Joachim Breitner authored
      The idea is described in #14152, and can be summarized: Float the exit
      path out of a joinrec, so that the simplifier can do more with it.
      See the test case for a nice example.
      The floating goes against what the simplifier usually does, hence we
      need to be careful not inline them back.
      The position of exitification in the pipeline was chosen after a small
      amount of experimentation, but may need to be improved. For example,
      exitification can allow rewrite rules to fire, but for that it would
      have to happen before the `simpl_phases`.
      Perf.haskell.org reports these nice performance wins:
          Nofib allocations
          fannkuch-redux    78446640  - 99.92%      64560
          k-nucleotide     109466384  - 91.32%    9502040
          simple            72424696  -  5.96%   68109560
          Nofib instruction counts
          fannkuch-redux  1744331636  -  3.86% 1676999519
          k-nucleotide    2318221965  -  6.30% 2172067260
          scs             1978470869  -  3.35% 1912263779
          simple           669858104  -  3.38%  647206739
          spectral-norm    186423292  -  5.37%  176411536
      Differential Revision: https://phabricator.haskell.org/D3903
  15. 26 Sep, 2017 1 commit
  16. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      Reviewed By: bgamari
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      Differential Revision: https://phabricator.haskell.org/D3989
  17. 31 Aug, 2017 1 commit
    • Simon Peyton Jones's avatar
      Add debugPprType · 805b29bb
      Simon Peyton Jones authored
      We pretty-print a type by converting it to an IfaceType and
      pretty-printing that.  But
       (a) that's a bit indirect, and
       (b) delibrately loses information about (e.g.) the kind
            on the /occurrences/ of a type variable
      So this patch implements debugPprType, which pretty prints
      the type directly, with no fancy formatting.  It's just used
      for debugging.
      I took the opportunity to refactor the debug-pretty-printing
      machinery a little.  In particular, define these functions
      and use them:
        ifPprDeubug :: SDoc -> SDOc -> SDoc
          -- Says what to do with and without -dppr-debug
        whenPprDebug :: SDoc -> SDoc
          -- Says what to do with  -dppr-debug; without is empty
        getPprDebug :: (Bool -> SDoc) -> SDoc
      getPprDebug used to be called sdocPprDebugWith
      whenPprDebug used to be called ifPprDebug
      So a lot of files get touched in a very mechanical way
  18. 25 Aug, 2017 1 commit
    • Simon Peyton Jones's avatar
      Refactor the Mighty Simplifier · 33452dfc
      Simon Peyton Jones authored
      Triggered by #12150, and the knock-on effects of join points, I did a
      major refactoring of the Simplifier.  This is a big patch that change
      a lot of Simplify.hs: I did a lot of other re-organisation.
      The main event
      Since the dawn of time we have had
        simplExpr :: SimplEnv -> InExpr -> SimplCont
                  -> SimplM (SimplEnv, OutExpr)
      What's that SimplEnv in the result?  When simplifying an expression the
      simplifier add floated let-bindings to the SimplEnv, extending the
      in-scope set appropriately, and hence needs to resturn the SimplEnv at
      the end.  The mode, flags, substitution in the returned SimplEnv were
      all irrelevant: it was just the floating bindings.
      It's strange to accumulate part of the /result/ in the /environment/
      argument!  And indeed its leads to all manner of mysterious calls to
      zapFloats and transferring of floats from one SimplEnv to another.
      It got worse with join points, so I finally bit the bullet and refactored.
      Now we have
        simplExpr :: SimplEnv -> InExpr -> SimplCont
                  -> SimplM (SimplFloats, OutExpr)
        -- See Note [The big picture]
      and the SimplEnv no longer has floats in it.  The code is no shorter,
      but it /is/ easier to understand.
      Main changes
      * Remove seLetFloats field from SimplEnv
      * Define new data type SimplFloats, and functions over it
      * Change the types of simplExpr, simplBind, and their many variants,
        to follow the above plan
      Bottoming bindings
      I made one other significant change in SimplUtils (not just refactoring),
      related to Trac #12150 comment:16.  Given
        x = <rhs>
      where <rhs> turns out to be a bottoming expression, propagate that
      information to x's IdInfo immediately.  That's always good, because
      it makes x be inlined less (we don't inline bottoming things), and
      it allows (case x of ...) to drop the dead alterantives immediately.
      Moreover, we are doing the analysis anyway, in tryEtaExpandRhs, which
      calls CoreArity.findRhsArity, which already does simple bottom analysis.
      So we are generating the information; all we need do is to atach the
      bottoming info to the IdInfo.
      See Note [Bottoming bindings]
      Smaller refactoring
      * Rename SimplifierMode to SimplMode
      * Put DynFlags as a new field in SimplMode, to make fewer
        monadic calls to getDynFlags.
      * Move the code in addPolyBind into abstractFloats
      * Move the "don't eta-expand join points" into tryEtaExpandRhs
  19. 31 Jul, 2017 1 commit
  20. 02 May, 2017 1 commit
    • Simon Peyton Jones's avatar
      Join-point refactoring · 71037b61
      Simon Peyton Jones authored
      This commit has a raft of refactorings that improve the treatment
      of join points.  I wasn't aiming so much as to gain performance as
      to make the code simpler.
      The two big things are these:
      * Make mkDupableCont work for SimplBind as well.  This is simpler than
        I thought and quite neat.  (Luke had aready done StrictArg.)  That's
        a win in its own right. But also now /all/ continuations can be made
      * Now that all continuations can be made dup-able, I could simplify
        mkDupableCont to return just one SimplCont, instead of two.
        That really is a worthwhile simlification!  Much easier to think
      Plus a bunch of smaller things:
      * Remove the join-arity that had been added to seIdSubst.
        It can be done more simply by putting it in DoneEx, which
        is the only constructor that actually needs it, and now we
        don't need the unsavoury isJoinIdInEnv_maybe.
      * Re-order the handling of join points in Simplify, so that we don't need
        the horrible resultTypeOfDupableCont
      * Add field names for StrictBind, StrictArg; and use them
      * Define simplMonad.newJoinId, and use it
      * Rename the seFloats field of SimplEnv to seLetFloats
      Binary sizes seem to go up slightly, but allocations generally
      improve, sometimes significantly.  I don't believe the runtime numbers
      are reliable enough to draw any conclusions about
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
                event          +1.1%    -12.0%     -0.2%     -0.2%     -8.7%
               fulsom          +1.9%    -11.8%    -10.0%    -10.0%     +5.3%
           last-piece          +2.3%     -1.2%     -1.2%     -1.2%     +0.0%
                 mate          +0.9%     -1.4%     -0.6%     -0.7%     +0.0%
           multiplier          +1.5%     -8.3%      0.17      0.17     +0.0%
               parser          +2.0%     +1.0%      0.04      0.04     +0.0%
              parstof          +1.5%     +0.7%      0.01      0.01     +0.0%
                sched          +1.3%     -6.1%      0.03      0.03     +0.0%
               simple          +1.8%     +1.0%     +9.7%     +9.6%     +0.0%
                  Min          +0.5%    -12.0%    -10.0%    -10.0%     -8.7%
                  Max          +3.0%     +1.0%    +14.2%    +14.2%    +50.0%
       Geometric Mean          +1.4%     -0.4%     +0.3%     +0.4%     +0.5%
      There's also a tests/perf/compiler improvement of 20% allocation in
      T6048.  I think it's because we now generate smaller code.
  21. 28 Apr, 2017 3 commits
    • Simon Peyton Jones's avatar
      Re-engineer caseRules to add tagToEnum/dataToTag · 193664d4
      Simon Peyton Jones authored
      See Note [Scrutinee Constant Folding] in SimplUtils
      * Add cases for tagToEnum and dataToTag. This is the main new
        bit.  It allows the simplifier to remove the pervasive uses
        of     case tagToEnum (a > b) of
                  False -> e1
                  True  -> e2
        and replace it by the simpler
               case a > b of
                  DEFAULT -> e1
                  1#      -> e2
        See Note [caseRules for tagToEnum]
        and Note [caseRules for dataToTag] in PrelRules.
      * This required some changes to the API of caseRules, and hence
        to code in SimplUtils.  See Note [Scrutinee Constant Folding]
        in SimplUtils.
      * Avoid duplication of work in the (unusual) case of
           case BIG + 3# of b
             DEFAULT -> e1
             6#      -> e2
        Previously we got
           case BIG of
             DEFAULT -> let b = BIG + 3# in e1
             3#      -> let b = 6#       in e2
        Now we get
           case BIG of b#
             DEFAULT -> let b = b' + 3# in e1
             3#      -> let b = 6#      in e2
      * Avoid duplicated code in caseRules
      A knock-on refactoring:
      * Move Note [Word/Int underflow/overflow] to Literal, as
        documentation to accompany mkMachIntWrap etc; and get
        rid of PrelRuls.intResult' in favour of mkMachIntWrap
    • Simon Peyton Jones's avatar
      Be a bit more eager to inline in a strict context · 29d88ee1
      Simon Peyton Jones authored
      If we see f (g x), and f is strict, we want to be a bit more eager to
      inline g, because it may well expose an eval (on x perhaps) that can
      be eliminated or shared.
      I saw this in nofib boyer2, function RewriteFuns.onewayunify1.  It
      showed up as a consequence of the preceding patch that makes the
      simplifier do less work (Trac #13379).  We had
         f d (g x)
      where f was a class-op. Previously we simplified both d and
      (g x) with a RuleArgCtxt (making g a bit more eager to inline).
      But now we simplify only d that way, then fire the rule, and
      only then simplify (g x).  Firing the rule produces a strict
      funciion, so we want to make a strict function encourage
      inlining a bit.
    • Simon Peyton Jones's avatar
      Cure exponential behaviour in the simplifier · a1b753e8
      Simon Peyton Jones authored
      This patch nails a Bad Bug exposed in Trac #13379. Roughly,
      a deeply-nested application like
         f (f (f ....) ) )
      could make the simplifier go exponential -- without producing
      an exponential-sized result!
      The reason was that we
        - simplified a (big) function argument
        - then decided to inline the function
        - then preInilneUnconditionally the argument
        - and then re-simplified the big argument
      And if the "big argument" itself had a similar structure
      things could get very bad.
      Once I'd understood, it was easy to fix:
      * See Note Note [Avoiding exponential behaviour] for an overview
      * The key change is that Simplify.simplLam now as a case for
        (isSimplified dup). This is what removes the perf bug.
      * But I also made simplCast more parsimonious about simplifying,
        avoiding doing so when the coercion is Refl
      * And similarly I now try to avoid simplifying arguments
        where possible before applying rules.
        See Note [Trying rewrite rules]
      The latter two points tackle common cases, and in those cases make the
      simplifier take fewer iterations.
  22. 14 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix CaseIdentity optimisation AGAIN · 82b40598
      Simon Peyton Jones authored
      In this commit
          commit 02ac2974
          Author: Simon Peyton Jones <simonpj@microsoft.com>
          Date:   Wed Nov 16 10:37:47 2011 +0000
          Fix CaseIdentity optimisaion
          In fixing one bug I'd introduced another;
             case x of { T -> T; F -> F }
          wasn't getting optmised!  Trivial to fix.
      I introduced yet another!  This line of code in SimplUtils.mkCase1
          check_eq (Var v)    (DataAlt con) []   = v == dataConWorkId con
                                                   -- Optimisation only
      is patently false when arg_tys is non-empty.  Astonishing that it
      has not shown up before now.
      Easily fixed though.  This was all shown up by Trac #13417, which is
      now fixed.
      Merge to 8.0, 8.2.
  23. 28 Feb, 2017 1 commit
    • Simon Peyton Jones's avatar
      The Early Inline Patch · 2effe18a
      Simon Peyton Jones authored
      This very small patch switches on sm_inline even in the InitialPhase
      (aka "gentle" phase).   There is no reason not to... and the results
      are astonishing.
      I think the peformance of GHC itself improves by about 5%; and some
      programs get much smaller, quicker.  Result: across the board
      irmprovements in
      compile time performance.  Here are the changes in perf/compiler;
      the numbers are decreases in compiler bytes-allocated:
        3%   T5837
        7%   parsing001
        9%   T12234
        35%  T9020
        9%   T3064
        13%  T9961
        20%  T13056
        5%   T9872d
        5%   T9872c
        5%   T9872b
        7%   T9872a
        5%   T783
        35%  T12227
        20%  T1969
      Plus in perf/should_run
        5%   lazy-bs-alloc
      It wasn't as easy as it sounds: I did a raft of preparatory work in
      earlier patches.  But it's great!
      Reviewers: austin, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D3203
  24. 26 Feb, 2017 1 commit
    • Joachim Breitner's avatar
      Ensure that Literals are in range · 6dfc5ebf
      Joachim Breitner authored
      This commit fixes several bugs related to case expressions
      involving numeric literals which are not in the range of values of
      their (fixed-width, integral) type.
      There is a new invariant on Literal: The argument of a MachInt[64]
      or MachWord[64] must lie within the range of the corresponding
      primitive type Int[64]# or Word[64]#, as defined by the target machine.
      This invariant is enforced in mkMachInt[64]/mkMachWord[64] by wrapping
      the argument to the target type's range if necessary.
      Test Plan: Test Plan: make slowtest TEST="T9533 T9533b T9533c T10245
      Trac issues: #9533, #10245, #10246, #13171
      Reviewers: simonmar, simonpj, austin, bgamari, nomeata
      Reviewed By: bgamari
      Subscribers: thomie, rwbarton
      Differential Revision: https://phabricator.haskell.org/D810
  25. 08 Feb, 2017 1 commit
    • Simon Peyton Jones's avatar
      Improve -dsuppress-coercions · 421308ef
      Simon Peyton Jones authored
      The -dsuppress-coercions flag was being ignored when printing the
      CastIt constructor in SimplUtils.SimplCont.  This fixes ths problem,
      and improves what is printed when suppressing coercions, to show the
      size of the suppressed coercion.
  26. 01 Feb, 2017 1 commit
  27. 24 Jan, 2017 2 commits
    • rwbarton's avatar
      Re-sort case alternatives after scrutinee constant folding (#13170) · abaa6815
      rwbarton authored
      Commit d3b546b1 added a "scrutinee constant folding" pass
      that rewrites a case expression whose scrutinee is an expression like
      x +# 3#. But case expressions are supposed to have their alternatives in
      sorted order, so when the scrutinee is (for example) negateInt# x#, we
      need to re-sort the alternatives after mapping their values.
      This showed up as a core lint failure when compiling System.Process.Posix:
          isSigIntQuit n = sig == sigINT || sig == sigQUIT
              where sig = fromIntegral (-n)
      Data.List.sortBy is supposed to be linear-time on sorted or reverse-sorted
      input, so it is probably not worth doing anything more clever than this.
      Test Plan: Added a new test T13170 for the above case.
      Reviewers: austin, hsyl20, simonpj, bgamari
      Reviewed By: hsyl20, simonpj, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D3008
      GHC Trac Issues: #13170
    • Sylvain Henry's avatar
      Ensure that scrutinee constant folding wraps numbers · 53e2e70a
      Sylvain Henry authored
      Test Plan: T13172
      Reviewers: rwbarton, simonpj, austin, bgamari
      Reviewed By: simonpj, bgamari
      Subscribers: simonpj, thomie
      Differential Revision: https://phabricator.haskell.org/D3009
      GHC Trac Issues: #13172
  28. 19 Jan, 2017 1 commit
    • Richard Eisenberg's avatar
      Update levity polymorphism · e7985ed2
      Richard Eisenberg authored
      This commit implements the proposal in
      https://github.com/ghc-proposals/ghc-proposals/pull/29 and
      Here are some of the pieces of that proposal:
      * Some of RuntimeRep's constructors have been shortened.
      * TupleRep and SumRep are now parameterized over a list of RuntimeReps.
      * This
      means that two types with the same kind surely have the same
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      * RepType.typePrimRep and friends now return a *list* of PrimReps. These
      functions can now work successfully on unboxed tuples. This change is
      necessary because we allow abstraction over unboxed tuple types and so
      always handle unboxed tuples specially as we did before.
      * We sometimes have to create an Id from a PrimRep. I thus split PtrRep
      * into
      LiftedRep and UnliftedRep, so that the created Ids have the right
      * The RepType.RepType type was removed, as it didn't seem to help with
      * much.
      * The RepType.repType function is also removed, in favor of typePrimRep.
      * I have waffled a good deal on whether or not to keep VoidRep in
      TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
      represented in RuntimeRep, and typePrimRep will never return a list
      VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
      imagine another design choice where we have a PrimRepV type that is
      with an extra constructor. That seemed to be a heavier design, though,
      and I'm
      not sure what the benefit would be.
      * The last, unused vestiges of # (unliftedTypeKind) have been removed.
      * There were several pretty-printing bugs that this change exposed;
      * these are fixed.
      * We previously checked for levity polymorphism in the types of binders.
      * But we
      also must exclude levity polymorphism in function arguments. This is
      hard to check
      for, requiring a good deal of care in the desugarer. See Note [Levity
      checking] in DsMonad.
      * In order to efficiently check for levity polymorphism in functions, it
      * was necessary
      to add a new bit of IdInfo. See Note [Levity info] in IdInfo.
      * It is now safe for unlifted types to be unsaturated in Core. Core Lint
      * is updated
      * We can only know strictness after zonking, so several checks around
      * strictness
      in the type-checker (checkStrictBinds, the check for unlifted variables
      under a ~
      pattern) have been moved to the desugarer.
      * Along the way, I improved the treatment of unlifted vs. banged
      * bindings. See
      Note [Strict binds checks] in DsBinds and #13075.
      * Now that we print type-checked source, we must be careful to print
      * ConLikes correctly.
      This is facilitated by a new HsConLikeOut constructor to HsExpr.
      Particularly troublesome
      are unlifted pattern synonyms that get an extra void# argument.
      * Includes a submodule update for haddock, getting rid of #.
      * New testcases:
      * Fixed tickets:
      * This also adds a test case for #13105. This test case is
      * "compile_fail" and
      succeeds, because I want the testsuite to monitor the error message.
      When #13105 is fixed, the test case will compile cleanly.
  29. 12 Jan, 2017 1 commit
  30. 09 Jan, 2017 1 commit
  31. 05 Jan, 2017 1 commit
    • Simon Peyton Jones's avatar
      Remove a redundant test · 26646418
      Simon Peyton Jones authored
      postInlineUnconditionally was testing for isExportedId, but it was
      /also/ testing for top-level-ness, which is redundant.  This patch
      just removes the redundant test, and documents it.
  32. 21 Dec, 2016 1 commit
  33. 09 Dec, 2016 1 commit
    • Sylvain Henry's avatar
      Scrutinee Constant Folding · d3b546b1
      Sylvain Henry authored
      This patch introduces new rules to perform constant folding through
      case t -# 10# of _ {  ===> case t of _ {
               5#      -> e1              15#     -> e1
               8#      -> e2              18#     -> e2
               DEFAULT -> e               DEFAULT -> e
      The initial motivation is that it allows "Merge Nested Cases"
      optimization to kick in and to further simplify the code
      (see Trac #12877).
      Currently we recognize the following operations for Word# and Int#: Add,
      Sub, Xor, Not and Negate (for Int# only).
      Test Plan: validate
      Reviewers: simonpj, austin, bgamari
      Reviewed By: simonpj, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2762
      GHC Trac Issues: #12877
  34. 22 Apr, 2016 1 commit
  35. 15 Apr, 2016 1 commit
  36. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      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
  37. 16 Jan, 2016 1 commit
    • Alan Zimmerman's avatar
      Work SourceText in for all integer literals · 3a1babd6
      Alan Zimmerman authored
      Certain syntactic elements have integers in them, such as fixity
      specifications, SPECIALISE pragmas and so on.
      The lexer will accept mult-radix literals, with arbitrary leading zeros
      in these.
      Bring in a SourceText field to each affected AST element to capture the
      original literal text for use with API Annotations.
      Affected hsSyn elements are
           -- See note [Pragma source text]
           data Activation = NeverActive
                           | AlwaysActive
                           | ActiveBefore SourceText PhaseNum
                                -- Active only *strictly before* this phase
                           | ActiveAfter SourceText PhaseNum
                                 -- Active in this phase and later
                           deriving( Eq, Data, Typeable )
                                     -- Eq used in comparing rules in HsDecls
           data Fixity = Fixity SourceText Int FixityDirection
             -- Note [Pragma source text]
             deriving (Data, Typeable)
            | HsTickPragma         -- A pragma introduced tick
               SourceText           -- Note [Pragma source text] in BasicTypes
                                                -- external span for this tick
                  -- Source text for the four integers used in the span.
                  -- See note [Pragma source text] in BasicTypes
               (LHsExpr id)
      Updates haddock submodule
      Test Plan: ./validate
      Reviewers: goldfire, bgamari, austin
      Reviewed By: bgamari
      Subscribers: thomie, mpickering
      Differential Revision: https://phabricator.haskell.org/D1781
      GHC Trac Issues: #11430