1. 02 May, 2022 1 commit
  2. 22 Apr, 2022 1 commit
    • Krzysztof Gogolewski's avatar
      Fixes to rubbish literals · f435d55f
      Krzysztof Gogolewski authored and  Marge Bot's avatar Marge Bot committed
      * In CoreToStg, the application 'RUBBISH[rep] x' was simplified
        to 'RUBBISH[rep]'. But it is possible that the result of the function
        is represented differently than the function.
      * In Unarise, 'LitRubbish (primRepToType prep)'
        is incorrect: LitRubbish takes a RuntimeRep such as IntRep,
        while primRepToType returns a type such as Any @(TYPE IntRep). Use
        primRepToRuntimeRep instead.
        This code is never run in the testsuite.
      * In StgToByteCode, all rubbish literals were assumed to be boxed.
        This code predates representation-polymorphic RubbishLit and I think
        it was not updated.
      
      I don't have a testcase for any of those issues, but the code looks
      wrong.
      f435d55f
  3. 02 Mar, 2022 1 commit
    • doyougnu's avatar
      GenStgAlt 3-tuple synonym --> Record type · 91a10cb0
      doyougnu authored and  Marge Bot's avatar Marge Bot committed
      This commit alters GenStgAlt from a type synonym to a Record with field
      accessors. In pursuit of #21078, this is not a required change but cleans
      up several areas for nicer code in the upcoming js-backend, and in GHC
      itself.
      
      GenStgAlt: 3-tuple -> record
      
      Stg.Utils: GenStgAlt 3-tuple -> record
      
      Stg.Stats: StgAlt 3-tuple --> record
      
      Stg.InferTags.Rewrite: StgAlt 3-tuple -> record
      
      Stg.FVs: GenStgAlt 3-tuple -> record
      
      Stg.CSE: GenStgAlt 3-tuple -> record
      
      Stg.InferTags: GenStgAlt 3-tuple --> record
      
      Stg.Debug: GenStgAlt 3-tuple --> record
      
      Stg.Lift.Analysis: GenStgAlt 3-tuple --> record
      
      Stg.Lift: GenStgAlt 3-tuple --> record
      
      ByteCode.Instr: GenStgAlt 3-tuple --> record
      
      Stg.Syntax: add GenStgAlt helper functions
      
      Stg.Unarise: GenStgAlt 3-tuple --> record
      
      Stg.BcPrep: GenStgAlt 3-tuple --> record
      
      CoreToStg: GenStgAlt 3-tuple --> record
      
      StgToCmm.Expr: GenStgAlt 3-tuple --> record
      
      StgToCmm.Bind: GenStgAlt 3-tuple --> record
      
      StgToByteCode: GenStgAlt 3-tuple --> r...
      91a10cb0
  4. 12 Feb, 2022 1 commit
    • Andreas Klebinger's avatar
      Tag inference work. · 0e93023e
      Andreas Klebinger authored and Matthew Pickering's avatar Matthew Pickering committed
      This does three major things:
      * Enforce the invariant that all strict fields must contain tagged
      pointers.
      * Try to predict the tag on bindings in order to omit tag checks.
      * Allows functions to pass arguments unlifted (call-by-value).
      
      The former is "simply" achieved by wrapping any constructor allocations with
      a case which will evaluate the respective strict bindings.
      
      The prediction is done by a new data flow analysis based on the STG
      representation of a program. This also helps us to avoid generating
      redudant cases for the above invariant.
      
      StrictWorkers are created by W/W directly and SpecConstr indirectly.
      See the Note [Strict Worker Ids]
      
      Other minor changes:
      
      * Add StgUtil module containing a few functions needed by, but
        not specific to the tag analysis.
      
      -------------------------
      Metric Decrease:
      	T12545
      	T18698b
      	T18140
      	T18923
              LargeRecord
      Metric Increase:
              LargeRecord
      	ManyAlternatives
      	ManyConstructors
      	T10421
      	T12425
      	T12707
      	T13035
      	T13056
      	T13253
      	T13253...
      0e93023e
  5. 06 Feb, 2022 1 commit
  6. 31 Jan, 2022 1 commit
    • doyougnu's avatar
      StgToCmm: decouple DynFlags, add StgToCmmConfig · 60a54a8f
      doyougnu authored and  Marge Bot's avatar Marge Bot committed
      StgToCmm: add Config, remove CgInfoDownwards
      
      StgToCmm: runC api change to take StgToCmmConfig
      
      StgToCmm: CgInfoDownad -> StgToCmmConfig
      
      StgToCmm.Monad: update getters/setters/withers
      
      StgToCmm: remove CallOpts in StgToCmm.Closure
      
      StgToCmm: remove dynflag references
      
      StgToCmm: PtrOpts removed
      
      StgToCmm: add TMap to config, Prof - dynflags
      
      StgToCmm: add omit yields to config
      
      StgToCmm.ExtCode: remove redundant import
      
      StgToCmm.Heap: remove references to dynflags
      
      StgToCmm: codeGen api change, DynFlags -> Config
      
      StgToCmm: remove dynflags in Env and StgToCmm
      
      StgToCmm.DataCon: remove dynflags references
      
      StgToCmm: remove dynflag references in DataCon
      
      StgToCmm: add backend avx flags to config
      
      StgToCmm.Prim: remove dynflag references
      
      StgToCmm.Expr: remove dynflag references
      
      StgToCmm.Bind: remove references to dynflags
      
      StgToCmm: move DoAlignSanitisation to Cmm.Type
      
      StgToCmm: remove PtrOpts in Cmm.Parser.y
      
      DynFlags: update ipInitCode api
      
      StgToCmm: Config Module is single source of truth
      
      StgToCmm: Lazy config breaks IORef deadlock
      
      testsuite: bump countdeps threshold
      
      StgToCmm.Config: strictify fields except UpdFrame
      
      Strictifying UpdFrameOffset causes the RTS build with stage1 to
      deadlock. Additionally, before the deadlock performance of the RTS
      is noticeably slower.
      
      StgToCmm.Config: add field descriptions
      
      StgToCmm: revert strictify on Module in config
      
      testsuite: update CountDeps tests
      
      StgToCmm: update comment, fix exports
      
      Specifically update comment about loopification passed into dynflags
      then stored into stgToCmmConfig. And remove getDynFlags from
      Monad.hs exports
      
      Types.Name: add pprFullName function
      
      StgToCmm.Ticky: use pprFullname, fixup ExtCode imports
      
      Cmm.Info: revert cmmGetClosureType removal
      
      StgToCmm.Bind: use pprFullName, Config update comments
      
      StgToCmm: update closureDescription api
      
      StgToCmm: SAT altHeapCheck
      
      StgToCmm: default render for Info table, ticky
      
      Use default rendering contexts for info table and ticky ticky, which should be independent of command line input.
      
      testsuite: bump count deps
      
      pprFullName: flag for ticky vs normal style output
      
      convertInfoProvMap: remove unused parameter
      
      StgToCmm.Config: add backend flags to config
      
      StgToCmm.Config: remove Backend from Config
      
      StgToCmm.Prim: refactor Backend call sites
      
      StgToCmm.Prim: remove redundant imports
      
      StgToCmm.Config: refactor vec compatibility check
      
      StgToCmm.Config: add allowQuotRem2 flag
      
      StgToCmm.Ticky: print internal names with parens
      
      StgToCmm.Bind: dispatch ppr based on externality
      
      StgToCmm: Add pprTickyname, Fix ticky naming
      
      Accidently removed the ctx for ticky SDoc output. The only relevant flag
      is sdocPprDebug which was accidental set to False due to using
      defaultSDocContext without altering the flag.
      
      StgToCmm: remove stateful fields in config
      
      fixup: config: remove redundant imports
      
      StgToCmm: move Sequel type to its own module
      
      StgToCmm: proliferate getCallMethod updated api
      
      StgToCmm.Monad: add FCodeState to Monad Api
      
      StgToCmm: add second reader monad to FCode
      
      fixup: Prim.hs: missed a merge conflict
      
      fixup: Match countDeps tests to HEAD
      
      StgToCmm.Monad: withState -> withCgState
      
      To disambiguate it from mtl withState. This withState shouldn't be
      returning the new state as a value. However, fixing this means tackling
      the knot tying in CgState and so is very difficult since it changes when
      the thunk of the knot is forced which either leads to deadlock or to
      compiler panic.
      60a54a8f
  7. 12 Jan, 2022 1 commit
  8. 11 Sep, 2021 1 commit
    • Sylvain Henry's avatar
      Canonicalize bignum literals · 089de88e
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      Before this patch Integer and Natural literals were desugared into "real"
      Core in Core prep. Now we desugar them directly into their final ConApp
      form in HsToCore. We only keep the double representation for BigNat#
      (literals larger than a machine Word/Int) which are still desugared in
      Core prep.
      
      Using the final form directly allows case-of-known-constructor to fire
      for bignum literals, fixing #20245.
      
      Slight increase (+2.3) in T4801 which is a pathological case with
      Integer literals.
      
      Metric Increase:
          T4801
          T11545
      089de88e
  9. 21 Jul, 2021 1 commit
  10. 22 Jun, 2021 1 commit
    • Sylvain Henry's avatar
      Put tracing functions into their own module · 14956cb8
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      Now that Outputable is independent of DynFlags, we can put tracing
      functions using SDocs into their own module that doesn't transitively
      depend on any GHC.Driver.* module.
      
      A few modules needed to be moved to avoid loops in DEBUG mode.
      14956cb8
  11. 05 Jun, 2021 1 commit
    • Simon Peyton Jones's avatar
      Re-do rubbish literals · 52a524f7
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      As #19882 pointed out, we were simply doing rubbish literals wrong.
      (I'll refrain from explaining the wrong-ness here -- see the ticket.)
      
      This patch fixes it by adding a Type (of kind RuntimeRep) as field of
      LitRubbish, rather than [PrimRep].
      
      The Note [Rubbish literals] in GHC.Types.Literal explains the details.
      52a524f7
  12. 20 May, 2021 1 commit
  13. 13 May, 2021 3 commits
    • Sylvain Henry's avatar
      Remove useless {-# LANGUAGE CPP #-} pragmas · 67a5a91e
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      67a5a91e
    • Sylvain Henry's avatar
      Fully remove HsVersions.h · 0ef11907
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      Replace uses of WARN macro with calls to:
      
        warnPprTrace :: Bool -> SDoc -> a -> a
      
      Remove the now unused HsVersions.h
      
      Bump haddock submodule
      0ef11907
    • Sylvain Henry's avatar
      Replace CPP assertions with Haskell functions · bfabf94f
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      There is no reason to use CPP. __LINE__ and __FILE__ macros are now
      better replaced with GHC's CallStack. As a bonus, assert error messages
      now contain more information (function name, column).
      
      Here is the mapping table (HasCallStack omitted):
      
        * ASSERT:   assert     :: Bool -> a -> a
        * MASSERT:  massert    :: Bool -> m ()
        * ASSERTM:  assertM    :: m Bool -> m ()
        * ASSERT2:  assertPpr  :: Bool -> SDoc -> a -> a
        * MASSERT2: massertPpr :: Bool -> SDoc -> m ()
        * ASSERTM2: assertPprM :: m Bool -> SDoc -> m ()
      bfabf94f
  14. 12 May, 2021 1 commit
    • Simon Peyton Jones's avatar
      Fix strictness and arity info in SpecConstr · c7717949
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      In GHC.Core.Opt.SpecConstr.spec_one we were giving join-points an
      incorrect join-arity -- this was fallout from
      
          commit c71b2204
          Author: Simon Peyton Jones <simonpj@microsoft.com>
          Date:   Thu Apr 8 23:36:24 2021 +0100
      
              Improvements in SpecConstr
      
              * Allow under-saturated calls to specialise
                See Note [SpecConstr call patterns]
                This just allows a bit more specialisation to take place.
      
      and showed up in #19780. I refactored the code to make the new
      function calcSpecInfo which treats join points separately.
      
      In doing this I discovered two other small bugs:
      
      * In the Var case of argToPat we were treating UnkOcc as
        uninteresting, but (by omission) NoOcc as interesting. As a
        result we were generating SpecConstr specialisations for functions
        with unused arguments.  But the absence anlyser does that much
        better; doing it here just generates more code.  Easily fixed.
      
      * The lifted/unlifted test in GHC.Core.Opt.WorkWrap.Utils.mkWorkerArgs
        was back to front (#19794).  Easily fixed.
      
      * In the same function, mkWorkerArgs, we were adding an extra argument
        nullary join points, which isn't necessary.  I added a test for
        this.  That in turn meant I had to remove an ASSERT in
        CoreToStg.mkStgRhs for nullary join points, which was always bogus
        but now trips; I added a comment to explain.
      c7717949
  15. 27 Apr, 2021 1 commit
    • Simon Peyton Jones's avatar
      Eliminate unsafeEqualityProof in CorePrep · 6c7fff0b
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      The main idea here is to avoid treating
        * case e of {}
        * case unsafeEqualityProof of UnsafeRefl co -> blah
      specially in CoreToStg.  Instead, nail them in CorePrep,
      by converting
      
         case e of {}
           ==>   e |> unsafe-co
      
         case unsafeEqualityProof of UnsafeRefl cv -> blah
           ==> blah[unsafe-co/cv]
      
      in GHC.Core.Prep.  Now expressions that we want to treat as trivial
      really are trivial.  We can get rid of cpExprIsTrivial.
      
      And we fix #19700.
      
      A downside is that, at least under unsafeEqualityProof, we substitute
      in types and coercions, which is more work. But a big advantage is
      that it's all very simple and principled: CorePrep really gets rid of
      the unsafeCoerce stuff, as it does empty case, runRW#, lazyId etc.
      
      I've updated the overview in GHC.Core.Prep, and added
        Note [Unsafe coercions] in GHC.Core.Prep
        Note [Implementing unsafeCoerce] in base:Unsafe.Coerce
      
      We get 3% fewer bytes allocated when compiling perf/compiler/T5631,
      which uses a lot of unsafeCoerces.  (It's a happy-generated parser.)
      
      Metric Decrease:
          T5631
      6c7fff0b
  16. 27 Mar, 2021 1 commit
    • Sebastian Graf's avatar
      Rubbish literals for all representations (#18983) · 57d21e6a
      Sebastian Graf authored and  Marge Bot's avatar Marge Bot committed
      This patch cleans up the complexity around WW's `mk_absent_let` by
      broadening the scope of `LitRubbish`. Rubbish literals now store the
      `PrimRep` they represent and are ultimately lowered in Cmm.
      This in turn allows absent literals of `VecRep` or `VoidRep`. The latter
      allows absent literals for unlifted coercions, as requested in #18983.
      
      I took the liberty to rewrite and clean up `Note [Absent fillers]` and
      `Note [Rubbish values]` to account for the new implementation and to
      make them more orthogonal in their description.
      
      I didn't add a new regression test, as `T18982` already contains the
      test in the ticket and its test output changes as expected.
      
      Fixes #18983.
      57d21e6a
  17. 20 Mar, 2021 5 commits
  18. 14 Mar, 2021 1 commit
    • Sebastian Graf's avatar
      Implement the UnliftedDatatypes extension · b73c9c5f
      Sebastian Graf authored and  Marge Bot's avatar Marge Bot committed
      GHC Proposal: 0265-unlifted-datatypes.rst
      Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/265
      Issues: #19523
      Implementation Details: Note [Implementation of UnliftedDatatypes]
      
      This patch introduces the `UnliftedDatatypes` extension. When this extension is
      enabled, GHC relaxes the restrictions around what result kinds are allowed in
      data declarations. This allows data types for which an unlifted or
      levity-polymorphic result kind is inferred.
      
      The most significant changes are in `GHC.Tc.TyCl`, where
      `Note [Implementation of UnliftedDatatypes]` describes the details of the
      implementation.
      
      Fixes #19523.
      b73c9c5f
  19. 03 Mar, 2021 2 commits
    • Matthew Pickering's avatar
      Add option to give each usage of a data constructor its own info table · a7aac008
      Matthew Pickering authored
      The `-fdistinct-constructor-tables` flag will generate a fresh info
      table for the usage of any data constructor. This is useful for
      debugging as now by inspecting the info table, you can determine which
      usage of a constructor caused that allocation rather than the old
      situation where the info table always mapped to the definition site of
      the data constructor which is useless.
      
      In conjunction with `-hi` and `-finfo-table-map` this gives a more fine
      grained understanding of where constructor allocations arise from in a
      program.
      a7aac008
    • Matthew Pickering's avatar
      Add -finfo-table-map which maps info tables to source positions · 4b297979
      Matthew Pickering authored
      This new flag embeds a lookup table from the address of an info table
      to information about that info table.
      
      The main interface for consulting the map is the `lookupIPE` C function
      
      > InfoProvEnt * lookupIPE(StgInfoTable *info)
      
      The `InfoProvEnt` has the following structure:
      
      > typedef struct InfoProv_{
      >     char * table_name;
      >     char * closure_desc;
      >     char * ty_desc;
      >     char * label;
      >     char * module;
      >     char * srcloc;
      > } InfoProv;
      >
      > typedef struct InfoProvEnt_ {
      >     StgInfoTable * info;
      >     InfoProv prov;
      >     struct InfoProvEnt_ *link;
      > } InfoProvEnt;
      
      The source positions are approximated in a similar way to the source
      positions for DWARF debugging information. They are only approximate but
      in our experience provide a good enough hint about where the problem
      might be. It is therefore recommended to use this flag in conjunction
      with `-g<n>` for more accurate locations.
      
      The lookup table is also emitted into the eventlog when it is available
      as it is intended to be used with the `-hi` profiling mode.
      
      Using this flag will significantly increase the size of the resulting
      object file but only by a factor of 2-3x in our experience.
      4b297979
  20. 01 Mar, 2021 1 commit
    • Simon Peyton Jones's avatar
      Fix terrible occurrence-analysis bug · 6429943b
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      Ticket #19360 showed up a terrible bug in the occurrence analyser,
      in a situation like this
      
         Rec { f = g
             ; g = ..f...
               {-# RULE g .. = ...f... #-}  }
      
      Then f was postInlineUnconditionally, but not in the RULE (which
      is simplified first), so we had a RULE mentioning a variable that
      was not in scope.
      
      This led me to review (again) the subtle loop-breaker stuff in the
      occurrence analyser. The actual changes are few, and are largely
      simplifications.  I did a /lot/ of comment re-organising though.
      
      There was an unexpected amount of fallout.
      
      * Validation failed when compiling the stage2 compiler with profiling
        on. That turned to tickle a second latent bug in the same OccAnal
        code (at least I think it was always there), which led me to
        simplify still further; see Note [inl_fvs] in GHC.Core.Opt.OccurAnal.
      
      * But that in turn let me to some strange behaviour in CSE when ticks
        are in the picture, which I duly fixed.  See Note [Dealing with ticks]
        in GHC.Core.Opt.CSE.
      
      * Then I got an ASSERT failure in CoreToStg, which again seems to be
        a latent bug.  See Note [Ticks in applications] in GHC.CoreToStg
      
      * I also made one unforced change: I now simplify the RHS of a RULE in
        the same way as the RHS of a stable unfolding. This can allow a
        trivial binding to disappear sooner than otherwise, and I don't
        think it has any downsides.  The change is in
        GHC.Core.Opt.Simplify.simplRules.
      6429943b
  21. 29 Jan, 2021 1 commit
    • Leif Metcalf's avatar
      Remove StgLam · 37378a0b
      Leif Metcalf authored and  Marge Bot's avatar Marge Bot committed
      StgLam is used exclusively in the work of CoreToStg, but there's nothing
      in the type of StgExpr that indicates this, so we're forced throughout
      the Stg.* codebase to handle cases like:
      
      case expr of
        ...
        StgLam lam -> panic "Unexpected StgLam"
        ...
      
      This patch removes the StgLam constructor from the base StgExpr so these
      cases no longer need to be handled. Instead, we use a new intermediate
      type in CoreToStg, PreStgRhs, to represent the RHS expression of a
      binding.
      37378a0b
  22. 22 Jan, 2021 1 commit
  23. 02 Jan, 2021 1 commit
    • Simon Peyton Jones's avatar
      Don't use absentError thunks for strict constructor fields · a8926e95
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      This patch fixes #19133 by using LitRubbish for strict constructor
      fields, even if they are of lifted types.  Previously LitRubbish
      worked only for unlifted (but boxed) types.
      
      The change is very easy, although I needed a boolean field in
      LitRubbish to say whether or not it is lifted.  (That seemed easier
      than giving it another type argument.
      
      This is preparing for Andreas's work on establishing the invariant
      that strict constructor fields are always tagged and evaluated
      (see #16970).
      
      Meanwhile, nothing was actually wrong before, so there are no tests.
      a8926e95
  24. 20 Nov, 2020 1 commit
    • Sebastian Graf's avatar
      Demand: Interleave usage and strictness demands (#18903) · 0aec78b6
      Sebastian Graf authored and  Marge Bot's avatar Marge Bot committed
      As outlined in #18903, interleaving usage and strictness demands not
      only means a more compact demand representation, but also allows us to
      express demands that we weren't easily able to express before.
      
      Call demands are *relative* in the sense that a call demand `Cn(cd)`
      on `g` says "`g` is called `n` times. *Whenever `g` is called*, the
      result is used according to `cd`". Example from #18903:
      
      ```hs
      h :: Int -> Int
      h m =
        let g :: Int -> (Int,Int)
            g 1 = (m, 0)
            g n = (2 * n, 2 `div` n)
            {-# NOINLINE g #-}
        in case m of
          1 -> 0
          2 -> snd (g m)
          _ -> uncurry (+) (g m)
      ```
      
      Without the interleaved representation, we would just get `L` for the
      strictness demand on `g`. Now we are able to express that whenever
      `g` is called, its second component is used strictly in denoting `g`
      by `1C1(P(1P(U),SP(U)))`. This would allow Nested CPR to unbox the
      division, for example.
      
      Fixes #18903.
      While fixing regressions, I also discovered and fixed #18957.
      
      Metric Decrease:
          T13253-spj
      0aec78b6
  25. 01 Nov, 2020 1 commit
  26. 04 Sep, 2020 1 commit
    • Ryan Scott's avatar
      Introduce isBoxedTupleDataCon and use it to fix #18644 · c1e54439
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      The code that converts promoted tuple data constructors to
      `IfaceType`s in `GHC.CoreToIface` was using `isTupleDataCon`, which
      conflates boxed and unboxed tuple data constructors. To avoid this,
      this patch introduces `isBoxedTupleDataCon`, which is like
      `isTupleDataCon` but only works for _boxed_ tuple data constructors.
      
      While I was in town, I was horribly confused by the fact that there
      were separate functions named `isUnboxedTupleCon` and
      `isUnboxedTupleTyCon` (similarly, `isUnboxedSumCon` and
      `isUnboxedSumTyCon`). It turns out that the former only works for
      data constructors, despite its very general name! I opted to rename
      `isUnboxedTupleCon` to `isUnboxedTupleDataCon` (similarly, I renamed
      `isUnboxedSumCon` to `isUnboxedSumDataCon`) to avoid this potential
      confusion, as well as to be more consistent with
      the naming convention I used for `isBoxedTupleDataCon`.
      
      Fixes #18644.
      c1e54439
  27. 12 Aug, 2020 1 commit
    • Sylvain Henry's avatar
      DynFlags: disentangle Outputable · accbc242
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      - put panic related functions into GHC.Utils.Panic
      - put trace related functions using DynFlags in GHC.Driver.Ppr
      
      One step closer making Outputable fully independent of DynFlags.
      
      Bump haddock submodule
      accbc242
  28. 25 Jul, 2020 1 commit
  29. 21 Jul, 2020 1 commit
    • Sylvain Henry's avatar
      DynFlags: remove use of sdocWithDynFlags from GHC.Stg.* (#17957) · 30caeee7
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      * add StgPprOpts datatype
      * remove Outputable instances for types that need `StgPprOpts` to be
        pretty-printed and explicitly call type specific ppr functions
      * add default `panicStgPprOpts` for panic messages (when it's not
        convenient to thread StgPprOpts or DynFlags down to the ppr function
        call)
      30caeee7
  30. 17 Jun, 2020 1 commit
    • Sylvain Henry's avatar
      Update compiler · 96aa5787
      Sylvain Henry authored and Ben Gamari's avatar Ben Gamari committed
      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
  31. 14 Jun, 2020 1 commit
    • Ben Gamari's avatar
      codeGen: Don't discard live case binders in unsafeEqualityProof logic · 9a7462fb
      Ben Gamari authored and  Marge Bot's avatar Marge Bot committed
      Previously CoreToStg would unconditionally discard cases of the form:
      
          case unsafeEqualityProof of wild { _ -> rhs }
      
      and rather replace the whole thing with `rhs`. However, in some cases
      (see #18227) the case binder is still live, resulting in unbound
      occurrences in `rhs`. Fix this by only discarding the case if the case
      binder is dead.
      
      Fixes #18227.
      9a7462fb
  32. 29 May, 2020 1 commit
    • Ben Gamari's avatar
      Eta expand un-saturated primops · 277c2f26
      Ben Gamari authored and  Marge Bot's avatar Marge Bot committed
      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
  33. 24 May, 2020 1 commit