1. 18 May, 2018 3 commits
    • Simon Peyton Jones's avatar
      Orient TyVar/TyVar equalities with deepest on the left · 2bbdd00c
      Simon Peyton Jones authored
      Trac #15009 showed that, for Given TyVar/TyVar equalities, we really
      want to orient them with the deepest-bound skolem on the left. As it
      happens, we also want to do the same for Wanteds, but for a different
      reason (more likely to be touchable).  Either way, deepest wins:
      see TcUnify Note [Deeper level on the left].
      
      This observation led me to some significant changes:
      
      * A SkolemTv already had a TcLevel, but the level wasn't really being
        used.   Now it is!
      
      * I updated added invariant (SkolInf) to TcType
        Note [TcLevel and untouchable type variables], documenting that
        the level number of all the ic_skols should be the same as the
        ic_tclvl of the implication
      
      * FlatSkolTvs and FlatMetaTvs previously had a dummy level-number of
        zero, which messed the scheme up.   Now they get a level number the
        same way as all other TcTyVars, instead of being a special case.
      
      * To make sure that FlatSkolTvs and FlatMetaTvs are untouchable (which
        was previously done via their magic zero level) isTouchableMetaTyVar
        just tests for those two cases.
      
      * TcUnify.swapOverTyVars is the crucial orientation function; see the
        new Note [TyVar/TyVar orientation].  I completely rewrote this function,
        and it's now much much easier to understand.
      
      I ended up doing some related refactoring, of course
      
      * I noticed that tcImplicitTKBndrsX and tcExplicitTKBndrsX were doing
        a lot of useless work in the case where there are no skolems; I
        added a fast-patch
      
      * Elminate the un-used tcExplicitTKBndrsSig; and thereby get rid of
        the higher-order parameter to tcExpliciTKBndrsX.
      
      * Replace TcHsType.emitTvImplication with TcUnify.checkTvConstraints,
        by analogy with TcUnify.checkConstraints.
      
      * Inline TcUnify.buildImplication into its only call-site in
        TcUnify.checkConstraints
      
      * TcS.buildImplication becomes TcS.CheckConstraintsTcS, with a
        simpler API
      
      * Now that we have NoEvBindsVar we have no need of termEvidenceAllowed;
        nuke the latter, adding Note [No evidence bindings] to TcEvidence.
      2bbdd00c
    • Simon Peyton Jones's avatar
      Tiny refactor · efe40544
      Simon Peyton Jones authored
      efe40544
    • Simon Peyton Jones's avatar
      Comments only · 797a4623
      Simon Peyton Jones authored
      797a4623
  2. 17 May, 2018 2 commits
  3. 16 May, 2018 7 commits
    • Ryan Scott's avatar
      Fix #15073 by suggesting UnboxedTuples in an error message · 0c7db226
      Ryan Scott authored
      Under certain circumstances, `GeneralizedNewtypeDeriving`
      can emit code which uses unboxed tuple types, but if `UnboxedTuples`
      wasn't enabled, the error message that GHC gave didn't make it very
      clear that it could be worked around by explicitly enabling the
      extension. Easily fixed.
      
      Test Plan: make test TEST=T15073
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, thomie, carter
      
      GHC Trac Issues: #15073
      
      Differential Revision: https://phabricator.haskell.org/D4620
      0c7db226
    • Ryan Scott's avatar
      Fix #15039 by pretty-printing equalities more systematically · 99f8cc84
      Ryan Scott authored
      GHC previously had a handful of special cases for
      pretty-printing equalities in a more user-friendly manner, but they
      were far from comprehensive (see #15039 for an example of where this
      fell apart).
      
      This patch makes the pretty-printing of equalities much more
      systematic. I've adopted the approach laid out in
      https://ghc.haskell.org/trac/ghc/ticket/15039#comment:4, and updated
      `Note [Equality predicates in IfaceType]` accordingly. We are now
      more careful to respect the properties of the
      `-fprint-explicit-kinds` and `-fprint-equality-relations` flags,
      which led to some improvements in error message outputs.
      
      Along the way, I also tweaked the error-reporting machinery not to
      print out the type of a typed hole when the type is an unlifted
      equality, since it's kind (`TYPE ('TupleRep '[])`) was more
      confusing than anything.
      
      Test Plan: make test TEST="T15039a T15039b T15039c T15039d"
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15039
      
      Differential Revision: https://phabricator.haskell.org/D4696
      99f8cc84
    • Andreas Klebinger's avatar
      Add pprTraceM to Outputable as analog to traceM. · 126b4125
      Andreas Klebinger authored
      Test Plan: ci, using it in monadic code.
      
      Reviewers: bgamari, mpickering
      
      Reviewed By: mpickering
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4697
      126b4125
    • Simon Marlow's avatar
      Merge FUN_STATIC closure with its SRT · 838b6903
      Simon Marlow authored
      Summary:
      The idea here is to save a little code size and some work in the GC,
      by collapsing FUN_STATIC closures and their SRTs.
      
      This is (4) in a series; see D4632 for more details.
      
      There's a tradeoff here: more complexity in the compiler in exchange
      for a modest code size reduction (probably around 0.5%).
      
      Results:
      * GHC binary itself (statically linked) is 1% smaller
      * -0.2% binary sizes in nofib (-0.5% module sizes)
      
      Full nofib results comparing D4634 with this: P177 (ignore runtimes,
      these aren't stable on my laptop)
      
      Test Plan: validate, nofib
      
      Reviewers: bgamari, niteria, simonpj, erikd
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4637
      838b6903
    • Simon Marlow's avatar
      Save a word in the info table on x86_64 · 2b0918c9
      Simon Marlow authored
      Summary:
      An info table with an SRT normally looks like this:
      
          StgWord64 srt_offset
          StgClosureInfo layout
          StgWord32 layout
          StgWord32 has_srt
      
      But we only need 32 bits for srt_offset on x86_64, because the small
      memory model requires that code segments are at most 2GB. So we can
      optimise this to
      
          StgClosureInfo layout
          StgWord32 layout
          StgWord32 srt_offset
      
      saving a word.  We can tell whether the info table has an SRT or not,
      because zero is not a valid srt_offset, so zero still indicates that
      there's no SRT.
      
      Test Plan:
      * validate
      * For results, see D4632.
      
      Reviewers: bgamari, niteria, osa1, erikd
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4634
      2b0918c9
    • Simon Marlow's avatar
      Allow CmmLabelDiffOff with different widths · fbd28e2c
      Simon Marlow authored
      Summary:
      This change makes it possible to generate a static 32-bit relative label
      offset on x86_64. Currently we can only generate word-sized label
      offsets.
      
      This will be used in D4634 to shrink info tables.  See D4632 for more
      details.
      
      Test Plan: See D4632
      
      Reviewers: bgamari, niteria, michalt, erikd, jrtc27, osa1
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4633
      fbd28e2c
    • Simon Marlow's avatar
      An overhaul of the SRT representation · eb8e692c
      Simon Marlow authored
      Summary:
      - Previously we would hvae a single big table of pointers per module,
        with a set of bitmaps to reference entries within it. The new
        representation is identical to a static constructor, which is much
        simpler for the GC to traverse, and we get to remove the complicated
        bitmap-traversal code from the GC.
      
      - Rewrite all the code to generate SRTs in CmmBuildInfoTables, and
        document it much better (see Note [SRTs]). This has been something
        I've wanted to do since we moved to the new code generator, I
        finally had the opportunity to finish it while on a transatlantic
        flight recently :)
      
      There are a series of 4 diffs:
      
      1. D4632 (this one), which does the bulk of the changes
      
      2. D4633 which adds support for smaller `CmmLabelDiffOff` constants
      
      3. D4634 which takes advantage of D4632 and D4633 to save a word in
         info tables that have an SRT on x86_64. This is where most of the
         binary size improvement comes from.
      
      4. D4637 which makes a further optimisation to merge some SRTs with
         static FUN closures.  This adds some complexity and the benefits
         are fairly modest, so it's not clear yet whether we should do this.
      
      Results (after (3), on x86_64)
      
      - GHC itself (staticaly linked) is 5.2% smaller
      
      - -1.7% binary sizes in nofib, -2.9% module sizes. Full nofib results: P176
      
      - I measured the overhead of traversing all the static objects in a
        major GC in GHC itself by doing `replicateM_ 1000 performGC` as the
        first thing in `Main.main`.  The new version was 5-10% faster, but
        the results did vary quite a bit.
      
      - I'm not sure if there's a compile-time difference, the results are
        too unreliable.
      
      Test Plan: validate
      
      Reviewers: bgamari, michalt, niteria, simonpj, erikd, osa1
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4632
      eb8e692c
  4. 15 May, 2018 4 commits
    • Artem Pelenitsyn's avatar
      Less Tc inside simplCore (Phase 1 for #14391) · bb3fa2d1
      Artem Pelenitsyn authored
      Simplifier depends on typechecker in two points: `thNameToGhcName`
      (`lookupThName_maybe`, in particular)  and `lookupGlobal`. We want to
      cut the ties in two steps.
      
      1. (Presented in this commit), reimplement both functions in a way that
      doesn't use typechecker.
      
      2. (Should follow), do code moving: a) `lookupGlobal` should go in some
      typechecker-free place; b) `thNameToGhcName` should leave simplifier,
      because it is not used there at all (probably, it should be placed
      somewhere where `GhcPlugins` can see it -- this is suggested by Joachim
      on Trac).
      
      Details
      =======
      
      We redesigned lookup interface a bit so that it exposes some
      `IO`-equivalents of `Tc`-features in use.
      
      First, `CoreMonad.hs` still calls `lookupGlobal` which is no longer
      bound to the typechecker monad, but still resides in `TcEnv.hs` — it
      should be moved out of Tc-land at some point (“Phase 2”) in the
      future in order to achieve its part of the #14391's goal.
      
      Second, `lookupThName_maybe` is eliminated from `CoreMonad.hs`
      completely; this already achieves its part of the goal of #14391. Its
      client, though, `thNameToGhcName`, is better to be moved in the future
      also, for it is not used in the `CoreMonad.hs` (or anywhere else)
      anyway. Joachim suggested “any module reexported by GhcPlugins (or
      maybe even that module itself)”.
      
      As a side goal, we removed `initTcForLookup` which was instrumental for
      the past version of `lookupGlobal`. This, in turn, called for pushing
      some more parts of the lookup interface from the `Tc`-monad to `IO`,
      most notably, adding `IO`-version of `lookupOrig` and pushing
      `dataConInfoPtrToName` to `IO`. The `lookupOrig` part, in turn,
      triggered a slight redesign of name cache updating interface: we now
      have both, `updNameCacheIO` and `updNameCacheTc`, both accepting `mod`
      and `occ` to force them inside, instead of more error-prone outside
      before. But all these hardly have to do anything with #14391, mere
      refactoring.
      
      Reviewers: simonpj, nomeata, bgamari, hvr
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14391
      
      Differential Revision: https://phabricator.haskell.org/D4503
      bb3fa2d1
    • Sebastian Graf's avatar
      Algebraically simplify add/sub with carry/overflow · bb338f2e
      Sebastian Graf authored
      Previously, the `{add,sub}{Int,Word}C#` PrimOps weren't handled
      in PrelRules (constant folding and algebraic simplification) at all.
      This implements the necessary logic, so that using these primitives
      isn't too punishing compared to their well-optimised, overflow-unaware
      counterparts.
      
      This is so that using these primitives in `enumFromThenTo @Int` can
      be optimized by constant folding, reducing closure sizes.
      
      Reviewers: bgamari, simonpj, hsyl20
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: AndreasK, thomie, carter
      
      GHC Trac Issues: #8763
      
      Differential Revision: https://phabricator.haskell.org/D4605
      bb338f2e
    • Ben Gamari's avatar
      Revert "Simplify callSiteInline a little" · 9dbf66d7
      Ben Gamari authored
      This lead to some rather significant performance regressions.
      Specifically,
      
          bytes allocated value is too high:
              Expected    T5631(normal) bytes allocated: 1106015512 +/-5%
              Lower bound T5631(normal) bytes allocated: 1050714736
              Upper bound T5631(normal) bytes allocated: 1161316288
              Actual      T5631(normal) bytes allocated: 1164953208
              Deviation   T5631(normal) bytes allocated:        5.3 %
          *** unexpected stat test failure for T5631(normal)
          max_bytes_used value is too high:
              Expected    T9630(normal) max_bytes_used: 35324712 +/-15%
              Lower bound T9630(normal) max_bytes_used: 30026005
              Upper bound T9630(normal) max_bytes_used: 40623419
              Actual      T9630(normal) max_bytes_used: 43490984
              Deviation   T9630(normal) max_bytes_used:     23.1 %
          *** unexpected stat test failure for T9630(normal)
      
      This reverts commit 7271db46.
      This reverts commit b750dcc5.
      This reverts commit 33de71fa.
      9dbf66d7
    • Simon Peyton Jones's avatar
      Tidy up error suppression · f49f90bb
      Simon Peyton Jones authored
      Trac #15152 showed that when a flag turned an error into a warning, we
      were still (alas) suppressing subequent errors; includign their
      essential addTcEvBind.  That led (rightly) to a Lint error.
      
      This patch fixes it, and incidentally tidies up an ad-hoc special
      case of out-of-scope variables (see the old binding for
      'out_of_scope_killer' in 'tryReporters').
      
      No test, because the problem was only shown up when turning
      inaccessible code into a warning.
      f49f90bb
  5. 14 May, 2018 6 commits
    • Tobias Dammers's avatar
      Fix performance regressions from #14737 · d92c7556
      Tobias Dammers authored
      See #15019. When removing an unnecessary type equality check in #14737,
      several regression tests failed. The cause was that some coercions that
      are actually Refl coercions weren't passed in as such, which made the
      equality check needlessly complex (Refl coercions can be discarded in
      this particular check immediately, without inspecting the types at all).
      
      We fix that, and get additional performance improvements for free.
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: simonpj, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4635
      d92c7556
    • Herbert Valerio Riedel's avatar
      Add support for opting out of package environments · 8f3c149d
      Herbert Valerio Riedel authored
      This implements the first part proposed in #13753:
      
      Define a special magic "null" environment, which instructs GHC to ignore
      any package environment files. To this end, I propose to use the name
      `-` (i.e. a single dash), as that is more portable than using the empty
      string for environment variables. In other words, a
      
      - `-package-env -` CLI flag, or a
      - `GHC_ENVIRONMENT=-` env var (unless a `-package-env` flag is present)
      
      would inhibit GHC from looking up and interpreting any package
      environment files from the filesystem; this is the equivalent of
      `-ignore-dot-ghci` for package environment files.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #13753
      
      Differential Revision: https://phabricator.haskell.org/D4690
      8f3c149d
    • Ben Gamari's avatar
      ghc-pkg: Configure handle encodings · cf88c2b1
      Ben Gamari authored
      This fixes #15021 using a the same approach as was used to fix the issue
      in ghc (#10762).
      
      Test Plan: Validate on Windows as user whose username contains
      non-ASCII characters
      
      Reviewers: simonmar
      
      Reviewed By: simonmar
      
      Subscribers: lehins, thomie, carter
      
      GHC Trac Issues: #15021
      
      Differential Revision: https://phabricator.haskell.org/D4642
      cf88c2b1
    • Ryan Scott's avatar
      Fix #14875 by introducing PprPrec, and using it · 21e1a00c
      Ryan Scott authored
      Trying to determine when to insert parentheses during TH
      conversion is a bit of a mess. There is an assortment of functions
      that try to detect this, such as:
      
      * `hsExprNeedsParens`
      * `isCompoundHsType`
      * `hsPatNeedsParens`
      * `isCompoundPat`
      * etc.
      
      To make things worse, each of them have slightly different semantics.
      Plus, they don't work well in the presence of explicit type
      signatures, as #14875 demonstrates.
      
      All of these problems can be alleviated with the use of an explicit
      precedence argument (much like what `showsPrec` currently does). To
      accomplish this, I introduce a new `PprPrec` data type, and define
      standard predences for things like function application, infix
      operators, function arrows, and explicit type signatures (that last
      one is new). I then added `PprPrec` arguments to the various
      `-NeedsParens` functions, and use them to make smarter decisions
      about when things need to be parenthesized.
      
      A nice side effect is that functions like `isCompoundHsType` are
      now completely unneeded, since they're simply aliases for
      `hsTypeNeedsParens appPrec`. As a result, I did a bit of refactoring
      to remove these sorts of functions. I also did a pass over various
      utility functions in GHC for constructing AST forms and used more
      appropriate precedences where convenient.
      
      Along the way, I also ripped out the existing `TyPrec`
      data type (which was tailor-made for pretty-printing `Type`s) and
      replaced it with `PprPrec` for consistency.
      
      Test Plan: make test TEST=T14875
      
      Reviewers: alanz, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14875
      
      Differential Revision: https://phabricator.haskell.org/D4688
      21e1a00c
    • Matthew Pickering's avatar
      Add note documenting refineDefaultAlt · bf6cad8b
      Matthew Pickering authored
      Reviewers: sjakobi, bgamari
      
      Reviewed By: sjakobi
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4687
      bf6cad8b
    • Chaitanya Koparkar's avatar
      GHCi: Include a note in the hint to expose a hidden package · 30c887d3
      Chaitanya Koparkar authored
      Test Plan: validate
      
      Reviewers: bgamari, RyanGlScott, osa1
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15055
      
      Differential Revision: https://phabricator.haskell.org/D4669
      30c887d3
  6. 13 May, 2018 5 commits
    • David Feuer's avatar
      Remove unused things from utils/Digraph · cdbe00fe
      David Feuer authored
      `utils/Digraph` had a bunch of code that wasn't actually being used,
      much of which wasn't documented at all, some of which was clearly
      ill-considered, and some of which was documented as being inefficient.
      
      Remove all unused code from that module except for the obvious and
      innocuous `emptyG`.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4676
      cdbe00fe
    • Sylvain Henry's avatar
      Refactor LitString · 7c665f9c
      Sylvain Henry authored
      Refactor LitString so that the string length is computed at most once
      and then stored.
      
      Also remove strlen and memcmp wrappers (it seems like they were a
      workaround for a very old GCC when using -fvia-C).
      
      Bumps haddock submodule.
      
      Reviewers: bgamari, dfeuer, nickkuk
      
      Reviewed By: bgamari, nickkuk
      
      Subscribers: nickkuk, dfeuer, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4630
      7c665f9c
    • Ben Gamari's avatar
      TcInteract: Ensure that tycons have representations before solving for Typeable · f0212a93
      Ben Gamari authored
      Summary: This fixes #15067.
      
      Test Plan: Validate
      
      Subscribers: thomie, carter, RyanGlScott
      
      GHC Trac Issues: #15067
      
      Differential Revision: https://phabricator.haskell.org/D4623
      f0212a93
    • Matthew Pickering's avatar
      Simplify -ddump-json implementation · 6ab7cf99
      Matthew Pickering authored
      This patch takes the much simpler route of whenever the compiler tries
      to output something. We just dump a JSON document there and then.
      
      I think this should be sufficient to work with and anything more refined
      quickly got complicated as it was necessary to demarcate message scopes
      and so on.
      
      Reviewers: bgamari, dfeuer
      
      Reviewed By: bgamari
      
      Subscribers: Phyx, dfeuer, rwbarton, thomie, carter
      
      GHC Trac Issues: #14078
      
      Differential Revision: https://phabricator.haskell.org/D4532
      6ab7cf99
    • Herbert Valerio Riedel's avatar
      Emit info-level log message when package envs are loaded · 00049e2d
      Herbert Valerio Riedel authored
      A common complaint with the new package environment files feature is
      that it's not obvious when package environments have been picked up.
      This patch applies the same strategy that was already used for `.ghci` files
      (which exhibit similar potential for confusion, c.f. #11389) to package
      environment files.
      
      For instance, this new notification looks like below for a GHCi invocation which
      loads both, a GHCi configuration as well as a package environment:
      
        GHCi, version 8.5.20180512: http://www.haskell.org/ghc/  :? for help
        Loaded package environment from /tmp/parsec-3.1.13.0/.ghc.environment.x86_64-linux-8.5.20180512
        Loaded GHCi configuration from /home/hvr/.ghci
        Prelude>
      
      Addresses #15145
      
      Reviewed By: bgamari, angerman
      
      GHC Trac Issues: #15145
      
      Differential Revision: https://phabricator.haskell.org/D4689
      00049e2d
  7. 12 May, 2018 2 commits
  8. 10 May, 2018 2 commits
    • Simon Marlow's avatar
      Revert "Add -fghci-leak-check to check for space leaks" · 87e169a3
      Simon Marlow authored
      This reverts commit 5fe6aaa3.
      87e169a3
    • Ömer Sinan Ağacan's avatar
      Fix #15038 · b2ff5dde
      Ömer Sinan Ağacan authored
      We introduce a new Id for unused pointer values in unboxed sums that is
      not CAFFY. Because the Id is not CAFFY it doesn't make non-CAFFY
      definitions CAFFY, fixing #15038.
      
      To make sure anything referenced by the new id will be retained we get a
      stable pointer to in on RTS startup.
      
      Test Plan: Passes validate
      
      Reviewers: simonmar, simonpj, hvr, bgamari, erikd
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15038
      
      Differential Revision: https://phabricator.haskell.org/D4680
      b2ff5dde
  9. 09 May, 2018 1 commit
    • Simon Marlow's avatar
      Add -fghci-leak-check to check for space leaks · 5fe6aaa3
      Simon Marlow authored
      Summary:
      Space leaks in GHCi emerge from time to time and tend to come back again
      after they get fixed. This is an attempt to limit regressions by
      
      * adding a reliable detection for some classes of space leaks in GHCi
      * turning on leak checking for all GHCi tests in the test suite, so that
        we'll notice if the leak appears again.
      
      The idea for detecting space leaks is quite simple:
      
      * find some data that we expect to be GC'd later, make a weak pointer to it
      * when we expect the data to be dead, do a `performGC` and then check
        the status of the weak pointer.
      
      It would be nice to apply this trick to lots of things in GHC,
      e.g. ensuring that HsSyn is not retained after the desugarer, or
      ensuring that CoreSyn from the previous simplifier pass is not retained.
      
      Test Plan: validate
      
      Reviewers: bgamari, simonpj, erikd, niteria
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15111
      
      Differential Revision: https://phabricator.haskell.org/D4658
      5fe6aaa3
  10. 08 May, 2018 7 commits
  11. 05 May, 2018 1 commit
    • Sebastian Graf's avatar
      Add 'addWordC#' PrimOp · 6243bba7
      Sebastian Graf authored
      This is mostly for congruence with 'subWordC#' and '{add,sub}IntC#'.
      I found 'plusWord2#' while implementing this, which both lacks
      documentation and has a slightly different specification than
      'addWordC#', which means the generic implementation is unnecessarily
      complex.
      
      While I was at it, I also added lacking meta-information on PrimOps
      and refactored 'subWordC#'s generic implementation to be branchless.
      
      Reviewers: bgamari, simonmar, jrtc27, dfeuer
      
      Reviewed By: bgamari, dfeuer
      
      Subscribers: dfeuer, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4592
      6243bba7