1. 15 Mar, 2020 1 commit
    • Sylvain Henry's avatar
      Refactor CmmToAsm (disentangle DynFlags) · 2e82465f
      Sylvain Henry authored
      This patch disentangles a bit more DynFlags from the native code
      generator (CmmToAsm).
      
      In more details:
      
      - add a new NCGConfig datatype in GHC.CmmToAsm.Config which contains the
        configuration of a native code generation session
      - explicitly pass NCGConfig/Platform arguments when necessary
      - as a consequence `sdocWithPlatform` is gone and there are only a few
        `sdocWithDynFlags` left
      - remove the use of `unsafeGlobalDynFlags` from GHC.CmmToAsm.CFG
      - remove `sdocDebugLevel` (now we pass the debug level via NCGConfig)
      
      There are still some places where DynFlags is used, especially because
      of pretty-printing (CLabel), because of Cmm helpers (such as
      `cmmExprType`) and because of `Outputable` instance for the
      instructions. These are left for future refactoring as this patch is
      already big.
      2e82465f
  2. 13 Mar, 2020 1 commit
    • Sylvain Henry's avatar
      Rename isDllName · 44fad4a9
      Sylvain Henry authored
      I wanted to fix the dangling comment in `isDllName` ("This is the cause
      of #", #8696 is already mentioned earlier). I took the opportunity to
      change the function name to better reflect what it does.
      44fad4a9
  3. 26 Feb, 2020 1 commit
  4. 22 Feb, 2020 1 commit
  5. 31 Jan, 2020 2 commits
    • Andreas Klebinger's avatar
      A few optimizations in STG and Cmm parts: · 2a87a565
      Andreas Klebinger authored
      (Guided by the profiler output)
      
      - Add a few bang patterns, INLINABLE annotations, and a seqList in a few
        places in Cmm and STG parts.
      
      - Do not add external variables as dependencies in STG dependency
        analysis (GHC.Stg.DepAnal).
      2a87a565
    • Ömer Sinan Ağacan's avatar
      Do CafInfo/SRT analysis in Cmm · c846618a
      Ömer Sinan Ağacan authored
      This patch removes all CafInfo predictions and various hacks to preserve
      predicted CafInfos from the compiler and assigns final CafInfos to
      interface Ids after code generation. SRT analysis is extended to support
      static data, and Cmm generator is modified to allow generating
      static_link fields after SRT analysis.
      
      This also fixes `-fcatch-bottoms`, which introduces error calls in case
      expressions in CorePrep, which runs *after* CoreTidy (which is where we
      decide on CafInfos) and turns previously non-CAFFY things into CAFFY.
      
      Fixes #17648
      Fixes #9718
      
      Evaluation
      ==========
      
      NoFib
      -----
      
      Boot with: `make boot mode=fast`
      Run: `make mode=fast EXTRA_RUNTEST_OPTS="-cachegrind" NoFibRuns=1`
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs    Instrs     Reads    Writes
      --------------------------------------------------------------------------------
                   CS          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                  CSD          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                   FS          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                    S          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                   VS          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                  VSD          -0.0%      0.0%     -0.0%     -0.0%     -0.5%
                  VSM          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 anna          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 ansi          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 atom          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               awards          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               banner          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
           bernouilli          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
         binary-trees          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                boyer          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               boyer2          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 bspt          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
            cacheprof          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
             calendar          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
             cichelli          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
              circsim          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
             clausify          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
        comp_lab_zift          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
             compress          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
            compress2          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
          constraints          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
         cryptarithm1          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
         cryptarithm2          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                  cse          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
         digits-of-e1          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
         digits-of-e2          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               dom-lt          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                eliza          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                event          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
          exact-reals          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               exp3_8          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               expert          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
       fannkuch-redux          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                fasta          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                  fem          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                  fft          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 fft2          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
             fibheaps          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 fish          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                fluid          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               fulsom          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               gamteb          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                  gcd          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
          gen_regexps          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               genfft          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                   gg          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 grep          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               hidden          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                  hpg          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  ida          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                infer          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
              integer          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
            integrate          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
         k-nucleotide          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                kahan          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
              knights          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               lambda          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
           last-piece          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 lcss          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 life          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 lift          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               linear          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            listcompr          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
             listcopy          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
             maillist          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               mandel          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
              mandel2          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 mate          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
              minimax          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
              mkhprog          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
           multiplier          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               n-body          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
             nucleic2          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 para          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
            paraffins          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               parser          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              parstof          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  pic          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
             pidigits          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                power          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               pretty          -0.0%      0.0%     -0.3%     -0.4%     -0.4%
               primes          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
            primetest          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               prolog          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               puzzle          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               queens          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
              reptile          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
      reverse-complem          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
              rewrite          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 rfib          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                  rsa          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                  scc          -0.0%      0.0%     -0.3%     -0.5%     -0.4%
                sched          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                  scs          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               simple          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                solid          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
              sorting          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
        spectral-norm          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               sphere          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
               symalg          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                  tak          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
            transform          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
             treejoin          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
            typecheck          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
              veritas          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 wang          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
            wave4main          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
         wheel-sieve1          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
         wheel-sieve2          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 x2n1          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
      --------------------------------------------------------------------------------
                  Min          -0.1%      0.0%     -0.3%     -0.5%     -0.5%
                  Max          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
       Geometric Mean          -0.0%     -0.0%     -0.0%     -0.0%     -0.0%
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs    Instrs     Reads    Writes
      --------------------------------------------------------------------------------
              circsim          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
          constraints          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
             fibheaps          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
             gc_bench          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 hash          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 lcss          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                power          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
           spellcheck          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
      --------------------------------------------------------------------------------
                  Min          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  Max          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
       Geometric Mean          -0.0%     +0.0%     -0.0%     -0.0%     -0.0%
      
      Manual inspection of programs in testsuite/tests/programs
      ---------------------------------------------------------
      
      I built these programs with a bunch of dump flags and `-O` and compared
      STG, Cmm, and Asm dumps and file sizes.
      
      (Below the numbers in parenthesis show number of modules in the program)
      
      These programs have identical compiler (same .hi and .o sizes, STG, and
      Cmm and Asm dumps):
      
      - Queens (1), andre_monad (1), cholewo-eval (2), cvh_unboxing (3),
        andy_cherry (7), fun_insts (1), hs-boot (4), fast2haskell (2),
        jl_defaults (1), jq_readsPrec (1), jules_xref (1), jtod_circint (4),
        jules_xref2 (1), lennart_range (1), lex (1), life_space_leak (1),
        bargon-mangler-bug (7), record_upd (1), rittri (1), sanders_array (1),
        strict_anns (1), thurston-module-arith (2), okeefe_neural (1),
        joao-circular (6), 10queens (1)
      
      Programs with different compiler outputs:
      
      - jl_defaults (1): For some reason GHC HEAD marks a lot of top-level
        `[Int]` closures as CAFFY for no reason. With this patch we no longer
        make them CAFFY and generate less SRT entries. For some reason Main.o
        is slightly larger with this patch (1.3%) and the executable sizes are
        the same. (I'd expect both to be smaller)
      
      - launchbury (1): Same as jl_defaults: top-level `[Int]` closures marked
        as CAFFY for no reason. Similarly `Main.o` is 1.4% larger but the
        executable sizes are the same.
      
      - galois_raytrace (13): Differences are in the Parse module. There are a
        lot, but some of the changes are caused by the fact that for some
        reason (I think a bug) GHC HEAD marks the dictionary for `Functor
        Identity` as CAFFY. Parse.o is 0.4% larger, the executable size is the
        same.
      
      - north_array: We now generate less SRT entries because some of array
        primops used in this program like `NewArrayOp` get eliminated during
        Stg-to-Cmm and turn some CAFFY things into non-CAFFY. Main.o gets 24%
        larger (9224 bytes from 9000 bytes), executable sizes are the same.
      
      - seward-space-leak: Difference in this program is better shown by this
        smaller example:
      
            module Lib where
      
            data CDS
              = Case [CDS] [(Int, CDS)]
              | Call CDS CDS
      
            instance Eq CDS where
              Case sels1 rets1 == Case sels2 rets2 =
                  sels1 == sels2 && rets1 == rets2
              Call a1 b1 == Call a2 b2 =
                  a1 == a2 && b1 == b2
              _ == _ =
                  False
      
         In this program GHC HEAD builds a new SRT for the recursive group of
         `(==)`, `(/=)` and the dictionary closure. Then `/=` points to `==`
         in its SRT field, and `==` uses the SRT object as its SRT. With this
         patch we use the closure for `/=` as the SRT and add `==` there. Then
         `/=` gets an empty SRT field and `==` points to `/=` in its SRT
         field.
      
         This change looks fine to me.
      
         Main.o gets 0.07% larger, executable sizes are identical.
      
      head.hackage
      ------------
      
      head.hackage's CI script builds 428 packages from Hackage using this
      patch with no failures.
      
      Compiler performance
      --------------------
      
      The compiler perf tests report that the compiler allocates slightly more
      (worst case observed so far is 4%). However most programs in the test
      suite are small, single file programs. To benchmark compiler performance
      on something more realistic I build Cabal (the library, 236 modules)
      with different optimisation levels. For the "max residency" row I run
      GHC with `+RTS -s -A100k -i0 -h` for more accurate numbers. Other rows
      are generated with just `-s`. (This is because `-i0` causes running GC
      much more frequently and as a result "bytes copied" gets inflated by
      more than 25x in some cases)
      
      * -O0
      
      |                 | GHC HEAD       | This MR        | Diff   |
      | --------------- | -------------- | -------------- | ------ |
      | Bytes allocated | 54,413,350,872 | 54,701,099,464 | +0.52% |
      | Bytes copied    |  4,926,037,184 |  4,990,638,760 | +1.31% |
      | Max residency   |    421,225,624 |    424,324,264 | +0.73% |
      
      * -O1
      
      |                 | GHC HEAD        | This MR         | Diff   |
      | --------------- | --------------- | --------------- | ------ |
      | Bytes allocated | 245,849,209,992 | 246,562,088,672 | +0.28% |
      | Bytes copied    |  26,943,452,560 |  27,089,972,296 | +0.54% |
      | Max residency   |     982,643,440 |     991,663,432 | +0.91% |
      
      * -O2
      
      |                 | GHC HEAD        | This MR         | Diff   |
      | --------------- | --------------- | --------------- | ------ |
      | Bytes allocated | 291,044,511,408 | 291,863,910,912 | +0.28% |
      | Bytes copied    |  37,044,237,616 |  36,121,690,472 | -2.49% |
      | Max residency   |   1,071,600,328 |   1,086,396,256 | +1.38% |
      
      Extra compiler allocations
      --------------------------
      
      Runtime allocations of programs are as reported above (NoFib section).
      
      The compiler now allocates more than before. Main source of allocation
      in this patch compared to base commit is the new SRT algorithm
      (GHC.Cmm.Info.Build). Below is some of the extra work we do with this
      patch, numbers generated by profiled stage 2 compiler when building a
      pathological case (the test 'ManyConstructors') with '-O2':
      
      - We now sort the final STG for a module, which means traversing the
        entire program, generating free variable set for each top-level
        binding, doing SCC analysis, and re-ordering the program. In
        ManyConstructors this step allocates 97,889,952 bytes.
      
      - We now do SRT analysis on static data, which in a program like
        ManyConstructors causes analysing 10,000 bindings that we would
        previously just skip. This step allocates 70,898,352 bytes.
      
      - We now maintain an SRT map for the entire module as we compile Cmm
        groups:
      
            data ModuleSRTInfo = ModuleSRTInfo
              { ...
              , moduleSRTMap :: SRTMap
              }
      
         (SRTMap is just a strict Map from the 'containers' library)
      
         This map gets an entry for most bindings in a module (exceptions are
         THUNKs and CAFFY static functions). For ManyConstructors this map
         gets 50015 entries.
      
      - Once we're done with code generation we generate a NameSet from SRTMap
        for the non-CAFFY names in the current module. This set gets the same
        number of entries as the SRTMap.
      
      - Finally we update CafInfos in ModDetails for the non-CAFFY Ids, using
        the NameSet generated in the previous step. This usually does the
        least amount of allocation among the work listed here.
      
      Only place with this patch where we do less work in the CAF analysis in
      the tidying pass (CoreTidy). However that doesn't save us much, as the
      pass still needs to traverse the whole program and update IdInfos for
      other reasons. Only thing we don't here do is the `hasCafRefs` pass over
      the RHS of bindings, which is a stateless pass that returns a boolean
      value, so it doesn't allocate much.
      
      (Metric changes blow are all increased allocations)
      
      Metric changes
      --------------
      
      Metric Increase:
          ManyAlternatives
          ManyConstructors
          T13035
          T14683
          T1969
          T9961
      c846618a
  6. 25 Jan, 2020 1 commit
  7. 13 Jan, 2020 1 commit
  8. 28 Nov, 2019 1 commit
  9. 21 Oct, 2019 1 commit
    • Ben Gamari's avatar
      rts: Implement concurrent collection in the nonmoving collector · bd8e3ff4
      Ben Gamari authored
      This extends the non-moving collector to allow concurrent collection.
      
      The full design of the collector implemented here is described in detail
      in a technical note
      
          B. Gamari. "A Concurrent Garbage Collector For the Glasgow Haskell
          Compiler" (2018)
      
      This extension involves the introduction of a capability-local
      remembered set, known as the /update remembered set/, which tracks
      objects which may no longer be visible to the collector due to mutation.
      To maintain this remembered set we introduce a write barrier on
      mutations which is enabled while a concurrent mark is underway.
      
      The update remembered set representation is similar to that of the
      nonmoving mark queue, being a chunked array of `MarkEntry`s. Each
      `Capability` maintains a single accumulator chunk, which it flushed
      when it (a) is filled, or (b) when the nonmoving collector enters its
      post-mark synchronization phase.
      
      While the write barrier touches a significant amount of code it is
      conceptually straightforward: the mutator must ensure that the referee
      of any pointer it overwrites is added to the update remembered set.
      However, there are a few details:
      
       * In the case of objects with a dirty flag (e.g. `MVar`s) we can
         exploit the fact that only the *first* mutation requires a write
         barrier.
      
       * Weak references, as usual, complicate things. In particular, we must
         ensure that the referee of a weak object is marked if dereferenced by
         the mutator. For this we (unfortunately) must introduce a read
         barrier, as described in Note [Concurrent read barrier on deRefWeak#]
         (in `NonMovingMark.c`).
      
       * Stable names are also a bit tricky as described in Note [Sweeping
         stable names in the concurrent collector] (`NonMovingSweep.c`).
      
      We take quite some pains to ensure that the high thread count often seen
      in parallel Haskell applications doesn't affect pause times. To this end
      we allow thread stacks to be marked either by the thread itself (when it
      is executed or stack-underflows) or the concurrent mark thread (if the
      thread owning the stack is never scheduled). There is a non-trivial
      handshake to ensure that this happens without racing which is described
      in Note [StgStack dirtiness flags and concurrent marking].
      Co-Authored-by: Ömer Sinan Ağacan's avatarÖmer Sinan Ağacan <omer@well-typed.com>
      bd8e3ff4
  10. 25 Jun, 2019 1 commit
  11. 20 Jun, 2019 1 commit
    • John Ericson's avatar
      Move 'Platform' to ghc-boot · bff2f24b
      John Ericson authored
      ghc-pkg needs to be aware of platforms so it can figure out which
      subdire within the user package db to use. This is admittedly
      roundabout, but maybe Cabal could use the same notion of a platform as
      GHC to good affect too.
      bff2f24b
  12. 29 May, 2019 1 commit
    • John Ericson's avatar
      Inline `Settings` into `DynFlags` · bfccd832
      John Ericson authored
      After the previous commit, `Settings` is just a thin wrapper around
      other groups of settings. While `Settings` is used by GHC-the-executable
      to initalize `DynFlags`, in principle another consumer of
      GHC-the-library could initialize `DynFlags` a different way. It
      therefore doesn't make sense for `DynFlags` itself (library code) to
      separate the settings that typically come from `Settings` from the
      settings that typically don't.
      bfccd832
  13. 14 May, 2019 1 commit
    • John Ericson's avatar
      Remove all target-specific portions of Config.hs · e529c65e
      John Ericson authored
      1. If GHC is to be multi-target, these cannot be baked in at compile
         time.
      
      2. Compile-time flags have a higher maintenance than run-time flags.
      
      3. The old way makes build system implementation (various bootstrapping
         details) with the thing being built. E.g. GHC doesn't need to care
         about which integer library *will* be used---this is purely a crutch
         so the build system doesn't need to pass flags later when using that
         library.
      
      4. Experience with cross compilation in Nixpkgs has shown things work
         nicer when compiler's can *optionally* delegate the bootstrapping the
         package manager. The package manager knows the entire end-goal build
         plan, and thus can make top-down decisions on bootstrapping. GHC can
         just worry about GHC, not even core library like base and ghc-prim!
      e529c65e
  14. 15 Apr, 2019 1 commit
    • Gabor Greif's avatar
      asm-emit-time IND_STATIC elimination · be05bd81
      Gabor Greif authored
      When a new closure identifier is being established to a
      local or exported closure already emitted into the same
      module, refrain from adding an IND_STATIC closure, and
      instead emit an assembly-language alias.
      
      Inter-module IND_STATIC objects still remain, and need to be
      addressed by other measures.
      
      Binary-size savings on nofib are around 0.1%.
      be05bd81
  15. 25 Mar, 2019 1 commit
    • Takenobu Tani's avatar
      Update Wiki URLs to point to GitLab · 3769e3a8
      Takenobu Tani authored
      This moves all URL references to Trac Wiki to their corresponding
      GitLab counterparts.
      
      This substitution is classified as follows:
      
      1. Automated substitution using sed with Ben's mapping rule [1]
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...
      
      2. Manual substitution for URLs containing `#` index
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz
      
      3. Manual substitution for strings starting with `Commentary`
          Old: Commentary/XxxYyy...
          New: commentary/xxx-yyy...
      
      See also !539
      
      [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
      3769e3a8
  16. 06 Mar, 2019 1 commit
    • Ben Gamari's avatar
      Rip out object splitting · 37f257af
      Ben Gamari authored
      The splitter is an evil Perl script that processes assembler code.
      Its job can be done better by the linker's --gc-sections flag. GHC
      passes this flag to the linker whenever -split-sections is passed on
      the command line.
      
      This is based on @DemiMarie's D2768.
      
      Fixes Trac #11315
      Fixes Trac #9832
      Fixes Trac #8964
      Fixes Trac #8685
      Fixes Trac #8629
      37f257af
  17. 22 Nov, 2018 1 commit
    • Sylvain Henry's avatar
      Rename literal constructors · 13bb4bf4
      Sylvain Henry authored
      In a previous patch we replaced some built-in literal constructors
      (MachInt, MachWord, etc.) with a single LitNumber constructor.
      
      In this patch we replace the `Mach` prefix of the remaining constructors
      with `Lit` for consistency (e.g., LitChar, LitLabel, etc.).
      
      Sadly the name `LitString` was already taken for a kind of FastString
      and it would become misleading to have both `LitStr` (literal
      constructor renamed after `MachStr`) and `LitString` (FastString
      variant). Hence this patch renames the FastString variant `PtrString`
      (which is more accurate) and the literal string constructor now uses the
      least surprising `LitString` name.
      
      Both `Literal` and `LitString/PtrString` have recently seen breaking
      changes so doing this kind of renaming now shouldn't harm much.
      
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers
      
      Subscribers: tdammers, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4881
      13bb4bf4
  18. 17 Nov, 2018 1 commit
  19. 15 Oct, 2018 1 commit
    • Zejun Wu's avatar
      Generate correct relocation for external cost centre · 95ec7c88
      Zejun Wu authored
      We used to always generate direct access for cost centre labels.  We
      fixed this by generating indirect data load for cost centre defined in
      external module.
      
      Test Plan:
      The added test used to fail with error message
      ```
      /bin/ld.gold: error: T15723B.o: requires dynamic R_X86_64_PC32 reloc
      against 'T15723A_foo1_EXPR_cc' which may overflow at runtime; recompile
      with -fPIC
      ```
      and now passes.
      
      Also check that `R_X86_64_PC32` is generated for CostCentre from the
      same module and `R_X86_64_GOTPCREL` is generated for CostCentre from
      external module:
      ```
      $ objdump -rdS T15723B.o
      0000000000000028 <T15723B_test_info>:
        28:   48 8d 45 f0             lea    -0x10(%rbp),%rax
        2c:   4c 39 f8                cmp    %r15,%rax
        2f:   72 70                   jb     a1 <T15723B_test_info+0x79>
        31:   48 83 ec 08             sub    $0x8,%rsp
        35:   48 8d 35 00 00 00 00    lea    0x0(%rip),%rsi        # 3c
      <T15723B_test_info+0x14>
                              38: R_X86_64_PC32
      T15723B_test1_EXPR_cc-0x4
        3c:   49 8b bd 60 03 00 00    mov    0x360(%r13),%rdi
        43:   31 c0                   xor    %eax,%eax
        45:   e8 00 00 00 00          callq  4a <T15723B_test_info+0x22>
                              46: R_X86_64_PLT32      pushCostCentre-0x4
        4a:   48 83 c4 08             add    $0x8,%rsp
        4e:   48 ff 40 30             incq   0x30(%rax)
        52:   49 89 85 60 03 00 00    mov    %rax,0x360(%r13)
        59:   48 83 ec 08             sub    $0x8,%rsp
        5d:   49 8b bd 60 03 00 00    mov    0x360(%r13),%rdi
        64:   48 8b 35 00 00 00 00    mov    0x0(%rip),%rsi        # 6b
      <T15723B_test_info+0x43>
                              67: R_X86_64_GOTPCREL   T15723A_foo1_EXPR_cc-0x4
        6b:   31 c0                   xor    %eax,%eax
        6d:   e8 00 00 00 00          callq  72 <T15723B_test_info+0x4a>
                              6e: R_X86_64_PLT32      pushCostCentre-0x4
        72:   48 83 c4 08             add    $0x8,%rsp
        76:   48 ff 40 30             incq   0x30(%rax)
      ```
      
      Reviewers: simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15723
      
      Differential Revision: https://phabricator.haskell.org/D5214
      95ec7c88
  20. 06 Oct, 2018 1 commit
    • Sergei Trofimovich's avatar
      UNREG: don't prefix asm prefixes in via-C mode · 4e3562c0
      Sergei Trofimovich authored
      commit 64c54fff
      ("Mark system and internal symbols as private symbols in asm")
      
      Added `internalNamePrefix` helper. Unfortunately it
      generates invalid label in unregisterised mode:
      
      ```
      $ ./configure --enable-unregisterised
      /tmp/ghc19372_0/ghc_4.hc:2831:22: error:
           error: expected identifier or '(' before '.' token
           static const StgWord .Lcl3_info[]__attribute__((aligned(8)))= {
                                ^
      ```
      
      Here asm-style prefix is applied to C symbol.
      The fix is simple: apply asm-style labels only to assembly code.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      
      Reviewers: simonmar, last_g, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5207
      4e3562c0
  21. 14 Sep, 2018 2 commits
    • Sergei Azovskov's avatar
      Mark code related symbols as @function not @object · c23f057f
      Sergei Azovskov authored
      Summary:
      This diff is a part of the bigger project which goal is to improve
      common profiling tools support (perf) for GHC binaries.
      
      A similar job was already done and reverted in the past:
       * https://phabricator.haskell.org/rGHCb1f453e16f0ce11a2ab18cc4c350bdcbd36299a6
       * https://phabricator.haskell.org/rGHCf1f3c4f50650110ad0f700d6566a44c515b0548f
      
      Reasoning:
      
      `Perf` and similar tools build in memory symbol table from the .symtab
      section of the ELF file to display human-readable function names instead
      of the addresses in the output. `Perf` uses only two types of symbols:
      `@function` and `@notype` but GHC is not capable to produce any
      `@function` symbols so the `perf` output is pretty useless (All the
      haskell symbols that you can see in `perf` now are `@notype` internal
      symbols extracted by mistake/hack).
      
      The changes:
       * mark code related symbols as @function
       * small hack to mark InfoTable symbols as code if TABLES_NEXT_TO_CODE is true
      
      Limitations:
       * The perf symbolization support is not complete after this patch but
         I'm working on the second patch.
       * Constructor symbols are not supported. To fix that we can issue extra
         local symbols which mark code sections as code and will be only used
         for debug.
      
      Test Plan:
      tests
      any additional ideas?
      
      Perf output on stock ghc 8.4.1:
      ```
           9.78%  FibbSlow  FibbSlow            [.] ckY_info
           9.59%  FibbSlow  FibbSlow            [.] cjqd_info
           7.17%  FibbSlow  FibbSlow            [.] c3sg_info
           6.62%  FibbSlow  FibbSlow            [.] c1X_info
           5.32%  FibbSlow  FibbSlow            [.] cjsX_info
           4.18%  FibbSlow  FibbSlow            [.] s3rN_info
           3.82%  FibbSlow  FibbSlow            [.] c2m_info
           3.68%  FibbSlow  FibbSlow            [.] cjlJ_info
           3.26%  FibbSlow  FibbSlow            [.] c3sb_info
           3.19%  FibbSlow  FibbSlow            [.] cjPQ_info
           3.05%  FibbSlow  FibbSlow            [.] cjQd_info
           2.97%  FibbSlow  FibbSlow            [.] cjAB_info
           2.78%  FibbSlow  FibbSlow            [.] cjzP_info
           2.40%  FibbSlow  FibbSlow            [.] cjOS_info
           2.38%  FibbSlow  FibbSlow            [.] s3rK_info
           2.27%  FibbSlow  FibbSlow            [.] cjq0_info
           2.18%  FibbSlow  FibbSlow            [.] cKQ_info
           2.13%  FibbSlow  FibbSlow            [.] cjSl_info
           1.99%  FibbSlow  FibbSlow            [.] s3rL_info
           1.98%  FibbSlow  FibbSlow            [.] c2cC_info
           1.80%  FibbSlow  FibbSlow            [.] s3rO_info
           1.37%  FibbSlow  FibbSlow            [.] c2f2_info
      ...
      ```
      
      Perf output on patched ghc:
      ```
           7.97%  FibbSlow  FibbSlow            [.] c3rM_info
           6.75%  FibbSlow  FibbSlow            [.] 0x000000000032cfa8
           6.63%  FibbSlow  FibbSlow            [.] cifA_info
           4.98%  FibbSlow  FibbSlow            [.] integerzmgmp_GHCziIntegerziType_eqIntegerzh_info
           4.55%  FibbSlow  FibbSlow            [.] chXn_info
           4.52%  FibbSlow  FibbSlow            [.] c3rH_info
           4.45%  FibbSlow  FibbSlow            [.] chZB_info
           4.04%  FibbSlow  FibbSlow            [.] Main_fibbzuslow_info
           4.03%  FibbSlow  FibbSlow            [.] stg_ap_0_fast
           3.76%  FibbSlow  FibbSlow            [.] chXA_info
           3.67%  FibbSlow  FibbSlow            [.] cifu_info
           3.25%  FibbSlow  FibbSlow            [.] ci4r_info
           2.64%  FibbSlow  FibbSlow            [.] s3rf_info
           2.42%  FibbSlow  FibbSlow            [.] s3rg_info
           2.39%  FibbSlow  FibbSlow            [.] integerzmgmp_GHCziIntegerziType_eqInteger_info
           2.25%  FibbSlow  FibbSlow            [.] integerzmgmp_GHCziIntegerziType_minusInteger_info
           2.17%  FibbSlow  FibbSlow            [.] ghczmprim_GHCziClasses_zeze_info
           2.09%  FibbSlow  FibbSlow            [.] cicc_info
           2.03%  FibbSlow  FibbSlow            [.] 0x0000000000331e15
           2.02%  FibbSlow  FibbSlow            [.] s3ri_info
           1.91%  FibbSlow  FibbSlow            [.] 0x0000000000331bb8
           1.89%  FibbSlow  FibbSlow            [.] ci4N_info
      ...
      ```
      
      Reviewers: simonmar, niteria, bgamari, goldfire
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: lelf, rwbarton, thomie, carter
      
      GHC Trac Issues: #15501
      
      Differential Revision: https://phabricator.haskell.org/D4713
      c23f057f
    • Sergei Azovskov's avatar
      Mark system and internal symbols as private symbols in asm · 64c54fff
      Sergei Azovskov authored
      Summary:
      This marks system and internal symbols as private in asm output so those
      random generated sysmbols won't appear in .symtab
      
      Reasoning:
       * internal symbols don't help to debug because names are just random
       * the symbols style breaks perf logic
       * internal symbols can take ~75% of the .symtab. In the same time
         .symtab can take about 20% of the binary file size
      
      Notice:
      This diff mostly makes sense on top of the D4713 (or similar)
      
      Test Plan:
      tests
      
      Perf from D4713
      ```
           7.97%  FibbSlow  FibbSlow            [.] c3rM_info
           6.75%  FibbSlow  FibbSlow            [.] 0x000000000032cfa8
           6.63%  FibbSlow  FibbSlow            [.] cifA_info
           4.98%  FibbSlow  FibbSlow            [.] integerzmgmp_GHCziIntegerziType_eqIntegerzh_info
           4.55%  FibbSlow  FibbSlow            [.] chXn_info
           4.52%  FibbSlow  FibbSlow            [.] c3rH_info
           4.45%  FibbSlow  FibbSlow            [.] chZB_info
           4.04%  FibbSlow  FibbSlow            [.] Main_fibbzuslow_info
           4.03%  FibbSlow  FibbSlow            [.] stg_ap_0_fast
           3.76%  FibbSlow  FibbSlow            [.] chXA_info
           3.67%  FibbSlow  FibbSlow            [.] cifu_info
           3.25%  FibbSlow  FibbSlow            [.] ci4r_info
           2.64%  FibbSlow  FibbSlow            [.] s3rf_info
           2.42%  FibbSlow  FibbSlow            [.] s3rg_info
           2.39%  FibbSlow  FibbSlow            [.] integerzmgmp_GHCziIntegerziType_eqInteger_info
           2.25%  FibbSlow  FibbSlow            [.] integerzmgmp_GHCziIntegerziType_minusInteger_info
           2.17%  FibbSlow  FibbSlow            [.] ghczmprim_GHCziClasses_zeze_info
           2.09%  FibbSlow  FibbSlow            [.] cicc_info
           2.03%  FibbSlow  FibbSlow            [.] 0x0000000000331e15
           2.02%  FibbSlow  FibbSlow            [.] s3ri_info
           1.91%  FibbSlow  FibbSlow            [.] 0x0000000000331bb8
           1.89%  FibbSlow  FibbSlow            [.] ci4N_info
      ...
      ```
      
      Perf from this patch:
      ```
          15.37%  FibbSlow  FibbSlow            [.] Main_fibbzuslow_info
          15.33%  FibbSlow  FibbSlow            [.] integerzmgmp_GHCziIntegerziType_minusInteger_info
          13.34%  FibbSlow  FibbSlow            [.] integerzmgmp_GHCziIntegerziType_eqIntegerzh_info
           9.24%  FibbSlow  FibbSlow            [.] integerzmgmp_GHCziIntegerziType_plusInteger_info
           9.08%  FibbSlow  FibbSlow            [.] frame_dummy
           8.25%  FibbSlow  FibbSlow            [.] integerzmgmp_GHCziIntegerziType_eqInteger_info
           4.29%  FibbSlow  FibbSlow            [.] 0x0000000000321ab0
           3.84%  FibbSlow  FibbSlow            [.] stg_ap_0_fast
           3.07%  FibbSlow  FibbSlow            [.] ghczmprim_GHCziClasses_zeze_info
           2.39%  FibbSlow  FibbSlow            [.] 0x0000000000321ab7
           1.90%  FibbSlow  FibbSlow            [.] 0x00000000003266b8
           1.88%  FibbSlow  FibbSlow            [.] base_GHCziNum_zm_info
           1.83%  FibbSlow  FibbSlow            [.] 0x0000000000326915
           1.34%  FibbSlow  FibbSlow            [.] 0x00000000003248cc
           1.07%  FibbSlow  FibbSlow            [.] base_GHCziNum_zp_info
           0.98%  FibbSlow  FibbSlow            [.] 0x00000000003247c8
           0.80%  FibbSlow  FibbSlow            [.] 0x0000000000121498
           0.79%  FibbSlow  FibbSlow            [.] stg_gc_noregs
           0.75%  FibbSlow  FibbSlow            [.] 0x0000000000321ad6
           0.67%  FibbSlow  FibbSlow            [.] 0x0000000000321aca
           0.64%  FibbSlow  FibbSlow            [.] 0x0000000000321b4a
           0.61%  FibbSlow  FibbSlow            [.] 0x00000000002ff633
      ```
      
      Reviewers: simonmar, niteria, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: lelf, angerman, olsner, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4722
      64c54fff
  22. 05 Jun, 2018 1 commit
    • Ömer Sinan Ağacan's avatar
      Rename some mutable closure types for consistency · 4075656e
      Ömer Sinan Ağacan authored
      SMALL_MUT_ARR_PTRS_FROZEN0 -> SMALL_MUT_ARR_PTRS_FROZEN_DIRTY
      SMALL_MUT_ARR_PTRS_FROZEN  -> SMALL_MUT_ARR_PTRS_FROZEN_CLEAN
      MUT_ARR_PTRS_FROZEN0       -> MUT_ARR_PTRS_FROZEN_DIRTY
      MUT_ARR_PTRS_FROZEN        -> MUT_ARR_PTRS_FROZEN_CLEAN
      
      Naming is now consistent with other CLEAR/DIRTY objects (MVAR, MUT_VAR,
      MUT_ARR_PTRS).
      
      (alternatively we could rename MVAR_DIRTY/MVAR_CLEAN etc. to MVAR0/MVAR)
      
      Removed a few comments in Scav.c about FROZEN0 being on the mut_list
      because it's now clear from the closure type.
      
      Reviewers: bgamari, simonmar, erikd
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4784
      4075656e
  23. 01 Jun, 2018 1 commit
    • Sergei Trofimovich's avatar
      UNREG: mark SRT as writable in generated C code · 9fd4ed90
      Sergei Trofimovich authored
      Noticed section mismatch on UNREG build failure:
      
      ```
        HC [stage 1] libraries/integer-gmp/dist-install/build/GHC/Integer/Type.o
      
           error: conflicting types for 'ufu0_srt'
           static StgWord ufu0_srt[]__attribute__((aligned(8)))= {
                          ^~~~~~~~
      
           note: previous declaration of 'ufu0_srt' was here
           IRO_(ufu0_srt);
                ^~~~~~~~
      ```
      
      `IRO_` is a 'const' qualifier.
      
      The error is a leftover from commit 838b6903
      "Merge FUN_STATIC closure with its SRT" where part of SRT was moved
      into closure itself and made SRTs writable.
      
      This change puts all SRTs into writable section.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      
      Reviewers: simonmar, bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4731
      9fd4ed90
  24. 23 May, 2018 2 commits
    • Ben Gamari's avatar
      Disable the SRT offset optimisation on MachO platforms · bf10456e
      Ben Gamari authored
      Unfortunately, this optimisation is infeasible on MachO platforms (e.g.
      Darwin) due to an object format limitation. Specifically, linking fails
      with errors of the form:
      
           error: unsupported relocation with subtraction expression, symbol
           '_integerzmgmp_GHCziIntegerziType_quotInteger_closure' can not be
           undefined in a subtraction expression
      
      Apparently MachO does not permit relocations' subtraction expressions to
      refer to undefined symbols. As far as I can tell this means that it is
      essentially impossible to express an offset between symbols living in
      different compilation units. This means that we lively can't use this
      optimisation on MachO platforms.
      
      Test Plan: Validate on Darwin
      
      Reviewers: simonmar, erikd
      
      Subscribers: rwbarton, thomie, carter, angerman
      
      GHC Trac Issues: #15169
      
      Differential Revision: https://phabricator.haskell.org/D4715
      bf10456e
    • Gabor Greif's avatar
      Typo in comments · 928f606b
      Gabor Greif authored
      928f606b
  25. 16 May, 2018 1 commit
    • 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
  26. 08 Mar, 2018 1 commit
    • Simon Marlow's avatar
      Add -fexternal-dynamic-refs · d99a65a8
      Simon Marlow authored
      Summary:
      The `-dynamic` flag does two things:
      
      * In the code generator, it generates code designed to link against
        external shared libraries.  References outside of the current module
        go through platform-specific indirection tables (e.g. the GOT on ELF).
      
      * It enables a "way", which changes which hi files we look
        for (`Foo.dyn_hi`) and which libraries we link against.
      
      Some specialised applications want the first of these without the
      second. (I could go into detail here but it's probably not all that
      important).
      
      This diff splits out the code-generation effects of `-dynamic` from the
      "way" parts of its behaviour, via a new flag `-fexternal-dynamic-refs`.
      
      Test Plan: validate
      
      Reviewers: niteria, bgamari, erikd
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4477
      d99a65a8
  27. 28 Nov, 2017 6 commits
  28. 15 Nov, 2017 2 commits
  29. 09 Nov, 2017 1 commit
    • Peter Trommler's avatar
      Fix PPC NCG after blockID patch · f8e7fece
      Peter Trommler authored
      Commit rGHC8b007ab assigns the same label to the first basic block
      of a proc and to the proc entry point. This violates the PPC 64-bit ELF
      v. 1.9 and v. 2.0 ABIs and leads to duplicate symbols.
      
      This patch fixes duplicate symbols caused by block labels
      
      In commit rGHCd7b8da1 an info table label is generated from a block id.
      Getting the entry label from that info label leads to an undefined
      symbol because a suffix "_entry" that is not present in the block label.
      
      To fix that issue add a new info table label flavour for labels
      derived from block ids. Converting such a label with toEntryLabel
      produces the original block label.
      
      Fixes #14311
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari, simonmar, erikd, hvr, angerman
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14311
      
      Differential Revision: https://phabricator.haskell.org/D4149
      f8e7fece
  30. 30 Oct, 2017 1 commit
    • Ben Gamari's avatar
      Add -falignment-sanitization flag · cecd2f2d
      Ben Gamari authored
      Here we add a flag to instruct the native code generator to add
      alignment checks in all info table dereferences. This is helpful in
      catching pointer tagging issues.
      
      Thanks to @jrtc27 for uncovering the tagging issues on Sparc which
      inspired this flag.
      
      Test Plan: Validate
      
      Reviewers: simonmar, austin, erikd
      
      Reviewed By: simonmar
      
      Subscribers: rwbarton, trofi, thomie, jrtc27
      
      Differential Revision: https://phabricator.haskell.org/D4101
      cecd2f2d
  31. 24 Sep, 2017 1 commit