1. 01 Oct, 2020 1 commit
  2. 26 Aug, 2020 1 commit
    • Krzysztof Gogolewski's avatar
      primops: Remove Monadic and Dyadic categories · 770100e0
      Krzysztof Gogolewski authored
      There were four categories of primops: Monadic, Dyadic, Compare, GenPrimOp.
      
      The compiler does not treat Monadic and Dyadic in any special way,
      we can just replace them with GenPrimOp.
      
      Compare is still used in isComparisonPrimOp.
      770100e0
  3. 22 Aug, 2020 1 commit
    • Aditya Gupta's avatar
      mkUnique refactoring (#18362) · e67ae884
      Aditya Gupta authored
      Move uniqFromMask from Unique.Supply to Unique.
      Move the the functions that call mkUnique from Unique to Builtin.Uniques
      e67ae884
  4. 07 Jul, 2020 1 commit
    • Sylvain Henry's avatar
      Optimise genericIntMul2Op · fdcc53ba
      Sylvain Henry authored
      We shouldn't directly call 'genericWordMul2Op' in genericIntMul2Op
      because a target may provide a faster primop for 'WordMul2Op': we'd
      better use it!
      fdcc53ba
  5. 28 Jun, 2020 1 commit
  6. 17 Jun, 2020 2 commits
    • Sylvain Henry's avatar
      Update compiler · 96aa5787
      Sylvain Henry authored
      Thanks to ghc-bignum, the compiler can be simplified:
      
      * Types and constructors of Integer and Natural can be wired-in. It
        means that we don't have to query them from interfaces. It also means
        that numeric literals don't have to carry their type with them.
      
      * The same code is used whatever ghc-bignum backend is enabled. In
        particular, conversion of bignum literals into final Core expressions
        is now much more straightforward. Bignum closure inspection too.
      
      * GHC itself doesn't depend on any integer-* package anymore
      
      * The `integerLibrary` setting is gone.
      96aa5787
    • Krzysztof Gogolewski's avatar
      Linear types (#15981) · 40fa237e
      Krzysztof Gogolewski authored
      This is the first step towards implementation of the linear types proposal
      (https://github.com/ghc-proposals/ghc-proposals/pull/111).
      
      It features
      
      * A language extension -XLinearTypes
      * Syntax for linear functions in the surface language
      * Linearity checking in Core Lint, enabled with -dlinear-core-lint
      * Core-to-core passes are mostly compatible with linearity
      * Fields in a data type can be linear or unrestricted; linear fields
        have multiplicity-polymorphic constructors.
        If -XLinearTypes is disabled, the GADT syntax defaults to linear fields
      
      The following items are not yet supported:
      
      * a # m -> b syntax (only prefix FUN is supported for now)
      * Full multiplicity inference (multiplicities are really only checked)
      * Decent linearity error messages
      * Linear let, where, and case expressions in the surface language
        (each of these currently introduce the unrestricted variant)
      * Multiplicity-parametric fields
      * Syntax for annotating lambda-bound or let-bound with a multiplicity
      * S...
      40fa237e
  7. 29 May, 2020 1 commit
    • Ben Gamari's avatar
      Eta expand un-saturated primops · 277c2f26
      Ben Gamari authored
      Now since we no longer try to predict CAFfyness we have no need for the
      solution to #16846. Eta expanding unsaturated primop applications is
      conceptually simpler, especially in the presence of levity polymorphism.
      
      This essentially reverts cac8dc9f,
      as suggested in #18079.
      
      Closes #18079.
      277c2f26
  8. 30 Apr, 2020 2 commits
    • Sylvain Henry's avatar
      Unit: split and rename modules · 8bfb0219
      Sylvain Henry authored
      Introduce GHC.Unit.* hierarchy for everything concerning units, packages
      and modules.
      
      Update Haddock submodule
      8bfb0219
    • Sylvain Henry's avatar
      Refactoring unit management code · 10d15f1e
      Sylvain Henry authored
      Over the years the unit management code has been modified a lot to keep
      up with changes in Cabal (e.g. support for several library components in
      the same package), to integrate BackPack, etc. I found it very hard to
      understand as the terminology wasn't consistent, was referring to past
      concepts, etc.
      
      The terminology is now explained as clearly as I could in the Note
      "About Units" and the code is refactored to reflect it.
      
      -------------------
      
      Many names were misleading: UnitId is not an Id but could be a virtual
      unit (an indefinite one instantiated on the fly), IndefUnitId
      constructor may contain a definite instantiated unit, etc.
      
         * Rename IndefUnitId into InstantiatedUnit
         * Rename IndefModule into InstantiatedModule
         * Rename UnitId type into Unit
         * Rename IndefiniteUnitId constructor into VirtUnit
         * Rename DefiniteUnitId constructor into RealUnit
         * Rename packageConfigId into mkUnit
         * Rename getPackageDetails into unsafeGetUnitInfo
         * Rename InstalledUnitId into UnitId
      
      Remove references to misleading ComponentId: a ComponentId is just an
      indefinite unit-id to be instantiated.
      
         * Rename ComponentId into IndefUnitId
         * Rename ComponentDetails into UnitPprInfo
         * Fix display of UnitPprInfo with empty version: this is now used for
           units dynamically generated by BackPack
      
      Generalize several types (Module, Unit, etc.) so that they can be used
      with different unit identifier types: UnitKey, UnitId, Unit, etc.
      
         * GenModule: Module, InstantiatedModule and InstalledModule are now
           instances of this type
         * Generalize DefUnitId, IndefUnitId, Unit, InstantiatedUnit,
           PackageDatabase
      
      Replace BackPack fake "hole" UnitId by a proper HoleUnit constructor.
      
      Add basic support for UnitKey. They should be used more in the future to
      avoid mixing them up with UnitId as we do now.
      
      Add many comments.
      
      Update Haddock submodule
      10d15f1e
  9. 26 Apr, 2020 1 commit
  10. 23 Apr, 2020 3 commits
  11. 18 Apr, 2020 2 commits
  12. 29 Mar, 2020 1 commit
  13. 18 Mar, 2020 1 commit
  14. 17 Mar, 2020 1 commit
  15. 26 Feb, 2020 1 commit
  16. 25 Jan, 2020 1 commit
  17. 13 Jan, 2020 1 commit
  18. 06 Jan, 2020 1 commit
  19. 31 Dec, 2019 1 commit
  20. 25 Sep, 2019 1 commit
    • Sebastian Graf's avatar
      PmCheck: Only ever check constantly many models against a single pattern · ebc65025
      Sebastian Graf authored
      Introduces a new flag `-fmax-pmcheck-deltas` to achieve that. Deprecates
      the old `-fmax-pmcheck-iter` mechanism in favor of this new flag.
      
      From the user's guide:
      
      Pattern match checking can be exponential in some cases. This limit makes sure
      we scale polynomially in the number of patterns, by forgetting refined
      information gained from a partially successful match. For example, when
      matching `x` against `Just 4`, we split each incoming matching model into two
      sub-models: One where `x` is not `Nothing` and one where `x` is `Just y` but
      `y` is not `4`. When the number of incoming models exceeds the limit, we
      continue checking the next clause with the original, unrefined model.
      
      This also retires the incredibly hard to understand "maximum number of
      refinements" mechanism, because the current mechanism is more general
      and should catch the same exponential cases like PrelRules at the same
      time.
      
      -------------------------
      Metric Decrease:
          T11822
      -------------------------
      ebc65025
  21. 26 Jun, 2019 1 commit
    • Ben Gamari's avatar
      Don't eta-expand unsaturated primops · cac8dc9f
      Ben Gamari authored
      Previously, as described in Note [Primop wrappers], `hasNoBinding` would
      return False in the case of `PrimOpId`s. This would result in eta
      expansion of unsaturated primop applications during CorePrep. Not only
      did this expansion result in unnecessary allocations, but it also meant
      lead to rather nasty inconsistencies between the CAFfy-ness
      determinations made by TidyPgm and CorePrep.
      
      This fixes #16846.
      cac8dc9f
  22. 14 Jun, 2019 1 commit
    • Ben Gamari's avatar
      PrelRules: Don't break let/app invariant in shiftRule · 5279dda8
      Ben Gamari authored
      Previously shiftRule would rewrite as invalid shift like
      ```
      let x = I# (uncheckedIShiftL# n 80)
      in ...
      ```
      to
      ```
      let x = I# (error "invalid shift")
      in ...
      ```
      However, this breaks the let/app invariant as `error` is not
      okay-for-speculation. There isn't an easy way to avoid this so let's not
      try. Instead we just take advantage of the undefined nature of invalid
      shifts and return zero.
      
      Fixes #16742.
      5279dda8
  23. 15 Mar, 2019 1 commit
  24. 24 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Add AnonArgFlag to FunTy · 6cce36f8
      Simon Peyton Jones authored
      The big payload of this patch is:
      
        Add an AnonArgFlag to the FunTy constructor
        of Type, so that
          (FunTy VisArg   t1 t2) means (t1 -> t2)
          (FunTy InvisArg t1 t2) means (t1 => t2)
      
      The big payoff is that we have a simple, local test to make
      when decomposing a type, leading to many fewer calls to
      isPredTy. To me the code seems a lot tidier, and probably
      more efficient (isPredTy has to take the kind of the type).
      
      See Note [Function types] in TyCoRep.
      
      There are lots of consequences
      
      * I made FunTy into a record, so that it'll be easier
        when we add a linearity field, something that is coming
        down the road.
      
      * Lots of code gets touched in a routine way, simply because it
        pattern matches on FunTy.
      
      * I wanted to make a pattern synonym for (FunTy2 arg res), which
        picks out just the argument and result type from the record. But
        alas the pattern-match overlap checker has a heart attack, and
        either reports false positives, or takes too long.  In the end
        I gave up on pattern synonyms.
      
        There's some commented-out code in TyCoRep that shows what I
        wanted to do.
      
      * Much more clarity about predicate types, constraint types
        and (in particular) equality constraints in kinds.  See TyCoRep
        Note [Types for coercions, predicates, and evidence]
        and Note [Constraints in kinds].
      
        This made me realise that we need an AnonArgFlag on
        AnonTCB in a TyConBinder, something that was really plain
        wrong before. See TyCon Note [AnonTCB InivsArg]
      
      * When building function types we must know whether we
        need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
        This turned out to be pretty easy in practice.
      
      * Pretty-printing of types, esp in IfaceType, gets
        tidier, because we were already recording the (->)
        vs (=>) distinction in an ad-hoc way.  Death to
        IfaceFunTy.
      
      * mkLamType needs to keep track of whether it is building
        (t1 -> t2) or (t1 => t2).  See Type
        Note [mkLamType: dictionary arguments]
      
      Other minor stuff
      
      * Some tidy-up in validity checking involving constraints;
        Trac #16263
      6cce36f8
  25. 10 Oct, 2018 1 commit
    • Ömer Sinan Ağacan's avatar
      Fix dataToTag# argument evaluation · ac977688
      Ömer Sinan Ağacan authored
      See #15696 for more details. We now always enter dataToTag# argument (done in
      generated Cmm, in StgCmmExpr). Any high-level optimisations on dataToTag#
      applications are done by the simplifier. Looking at tag bits (instead of
      reading the info table) for small types is left to another diff.
      
      Incorrect test T14626 is removed. We no longer do this optimisation (see
      comment:44, comment:45, comment:60).
      
      Comments and notes about special cases around dataToTag# are removed. We no
      longer have any special cases around it in Core.
      
      Other changes related to evaluating primops (seq# and dataToTag#) will be
      pursued in follow-up diffs.
      
      Test Plan: Validates with three regression tests
      
      Reviewers: simonpj, simonmar, hvr, bgamari, dfeuer
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15696
      
      Differential Revision: https://phabricator.haskell.org/D5201
      ac977688
  26. 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
      modules.
      
      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
      f63bc730
  27. 09 Sep, 2017 1 commit
  28. 28 Apr, 2017 1 commit
    • Simon Peyton Jones's avatar
      Improve code generation for conditionals · 6d14c148
      Simon Peyton Jones authored
      This patch in in preparation for the fix to Trac #13397
      
      The code generator has a special case for
        case tagToEnum (a>#b) of
          False -> e1
          True  -> e2
      
      but it was not doing nearly so well on
        case a>#b of
          DEFAULT -> e1
          1#      -> e2
      
      This patch arranges to behave essentially identically in
      both cases.  In due course we can eliminate the special
      case for tagToEnum#, once we've completed Trac #13397.
      
      The changes are:
      
      * Make CmmSink swizzle the order of a conditional where necessary;
        see Note [Improving conditionals] in CmmSink
      
      * Hack the general case of StgCmmExpr.cgCase so that it use
        NoGcInAlts for conditionals.  This doesn't seem right, but it's
        the same choice as the tagToEnum version. Without it, code size
        increases a lot (more heap checks).
      
        There's a loose end here.
      
      * Add comments in CmmOpt.cmmMachOpFoldM
      6d14c148
  29. 01 Feb, 2017 1 commit
  30. 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
      https://github.com/ghc-proposals/ghc-proposals/pull/35.
      
      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
      representation.
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      false.
      
      * 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
      cannot
      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
      strictness.
      
      * 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
      including
      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
      PrimRep
      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
      polymorphism
      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
      accordingly.
      
      * 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:
        typecheck/should_fail/StrictBinds
        typecheck/should_fail/T12973
        typecheck/should_run/StrictPats
        typecheck/should_run/T12809
        typecheck/should_fail/T13105
        patsyn/should_fail/UnliftedPSBind
        typecheck/should_fail/LevPolyBounded
        typecheck/should_compile/T12987
        typecheck/should_compile/T11736
      
      * Fixed tickets:
        #12809
        #12973
        #11736
        #13075
        #12987
      
      * 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.
      e7985ed2
  31. 07 Dec, 2016 1 commit
    • Alan Zimmerman's avatar
      Add HsSyn prettyprinter tests · 499e4382
      Alan Zimmerman authored
      Summary:
      Add prettyprinter tests, which take a file, parse it, pretty print it,
      re-parse the pretty printed version and then compare the original and
      new ASTs (ignoring locations)
      
      Updates haddock submodule to match the AST changes.
      
      There are three issues outstanding
      
      1. Extra parens around a context are not reproduced. This will require an
         AST change and will be done in a separate patch.
      
      2. Currently if an `HsTickPragma` is found, this is not pretty-printed,
         to prevent noise in the output.
      
         I am not sure what the desired behaviour in this case is, so have left
         it as before. Test Ppr047 is marked as expected fail for this.
      
      3. Apart from in a context, the ParsedSource AST keeps all the parens from
         the original source.  Something is happening in the renamer to remove the
         parens around visible type application, causing T12530 to fail, as the
         dumped splice decl is after the renamer.
      
         This needs to be fixed by keeping the parens, but I do not know where they
         are being removed.  I have amended the test to pass, by removing the parens
         in the expected output.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, mpickering, simonpj, bgamari, austin
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: simonpj, goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2752
      
      GHC Trac Issues: #3384
      499e4382
  32. 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
  33. 10 Apr, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Reduce default for -fmax-pmcheck-iterations from 1e7 to 2e6 · d2e05c6b
      Herbert Valerio Riedel authored
      The commit 28f951ed introduced the
      `-fmax-pmcheck-iterations` flag and set the default limit to 1e7
      iterations.
      
      However, this value is still high enough that it can result GHC to
      exhibit memory spikes beyond 1 GiB of RAM usage (heap profile showed
      several `(:)`s, as well as `THUNK_2_0`, and `PmCon` during the memory
      spikes)
      
      A value of 2e6 seems to be a safer upper bound which still manages to
      let the checker not run into the limit in most cases.
      
      Test Plan: Validate, try building a few Hackage packages
      
      Reviewers: austin, gkaracha, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2095
      d2e05c6b
  34. 24 Feb, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Address #11471 by putting RuntimeRep in kinds. · d8c64e86
      eir@cis.upenn.edu authored
      See Note [TYPE] in TysPrim. There are still some outstanding
      pieces in #11471 though, so this doesn't actually nail the bug.
      
      This commit also contains a few performance improvements:
      
      * Short-cut equality checking of nullary type syns
      
      * Compare types before kinds in eqType
      
      * INLINE coreViewOneStarKind
      
      * Store tycon binders separately from kinds.
      
      This resulted in a ~10% performance improvement in compiling
      the Cabal package. No change in functionality other than
      performance. (This affects the interface file format, though.)
      
      This commit updates the haddock submodule.
      d8c64e86
  35. 24 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Visible type application · 2db18b81
      eir@cis.upenn.edu authored
      This re-working of the typechecker algorithm is based on
      the paper "Visible type application", by Richard Eisenberg,
      Stephanie Weirich, and Hamidhasan Ahmed, to be published at
      ESOP'16.
      
      This patch introduces -XTypeApplications, which allows users
      to say, for example `id @Int`, which has type `Int -> Int`. See
      the changes to the user manual for details.
      
      This patch addresses tickets #10619, #5296, #10589.
      2db18b81