GitLab

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 <omer@well-typed.com>

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.

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.

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!

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%.

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

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

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

PR: https://github.com/ghc/ghc/pull/223/

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

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: Sergei Trofimovich <slyfox@gentoo.org>

Reviewers: simonmar, last_g, bgamari

Reviewed By: simonmar

Subscribers: rwbarton, carter

Differential Revision: https://phabricator.haskell.org/D5207

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

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

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

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: Sergei Trofimovich <slyfox@gentoo.org>

Reviewers: simonmar, bgamari

Subscribers: rwbarton, thomie, carter

Differential Revision: https://phabricator.haskell.org/D4731

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

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

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

Silly rabbit, BlockInfoTables are data. This fixes the unregisterised build,
finally fixing #14454.

blockLbl was originally changed in 8b007abb to
use mkTempAsmLabel to fix an inconsistency resulting in #14221. However, this
breaks the C code generator, which doesn't support AsmTempLabels (#14454).

Instead let's try going the other direction: use a new CLabel variety,
LocalBlockLabel. Then we can teach the C code generator to deal with
these as well.

Reviewers: simonmar

Subscribers: rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D4188

Test Plan: Validate

Reviewers: trommler, simonmar

Reviewed By: trommler

Subscribers: rwbarton, thomie

GHC Trac Issues: #14454

Differential Revision: https://phabricator.haskell.org/D4182

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

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

AsmTempLabel is really a label that describes
label in assembly output (or equivalent like LLVM IR).

Unregisterised build does not handle it correctly.

This change does not fix UNREG build failure in
Ticket #14264 but reverts back to panic:
    pprCLbl AsmTempLabel
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Summary:
This is another fallout from 8b007abb
should fix Trac #14264. I am not sure if this is
complete. It does however allow me to build an iOS
LLVM cross compiler.

Reviewers: bgamari, trofi, austin, simonmar

Reviewed By: trofi

Subscribers: rwbarton, thomie

GHC Trac Issues: #14264

Differential Revision: https://phabricator.haskell.org/D4014

This switches the compiler/ component to get compiled with
-XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
modules.

This is motivated by the upcoming "Prelude" re-export of
`Semigroup((<>))` which would cause lots of name clashes in every
modulewhich imports also `Outputable`

Reviewers: austin, goldfire, bgamari, alanz, simonmar

Reviewed By: bgamari

Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari

Differential Revision: https://phabricator.haskell.org/D3989

Consider one-line module
    module B (v) where v = "hello"
in -fvia-C mode it generates code like
    static char gibberish_str[] = "hello";

It resides in data section (precious resource on ia64!).
The patch switches genrator to emit:
    static const char gibberish_str[] = "hello";

Other types if symbols that gained 'const' qualifier are:

- info tables (from haskell and CMM)
- static reference tables (from haskell and CMM)

Cleanups along the way:

- fixed info tables defined in .cmm to reside in .rodata
- split out closure declaration into 'IC_' / 'EC_'
- added label declaration (based on label type) right before
  each label definition (based on section type) so that C
  compiler could check if declaration and definition matches
  at definition site.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: ran testsuite on unregisterised x86_64 compiler

Reviewers: simonmar, ezyang, austin, bgamari, erikd

Reviewed By: bgamari, erikd

Subscribers: rwbarton, thomie

GHC Trac Issues: #8996

Differential Revision: https://phabricator.haskell.org/D3481

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Before ghc-7.2 hs_add_root() had to be used to initialize haskell
modules when haskell was called from FFI.

commit a52ff761
("Change the way module initialisation is done (#3252, #4417)")
removed needs for hs_add_root() and made function a no-op.
For backward compatibility '__stginit_<module>' symbol was
not removed.

This change removes no-op hs_add_root() function and unused
'__stginit_<module>' symbol from each haskell module.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: ./validate

Reviewers: simonmar, austin, bgamari, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3460

I found that tests
  parser/should_compile/DumpRenamedAst
and friends were printing uniques, which makes the test fragile.
But -dsuppress-uniques made no difference!  It turned out that
pprName wasn't properly consulting Opt_SuppressUniques.

This patch fixes the problem, and updates those three tests to
use -dsuppress-uniques

Typical UNREG build failure looks like that:

  ghc-unreg/includes/Stg.h:226:46: error:
     note: in definition of macro 'EI_'
     #define EI_(X)          extern StgWordArray (X) GNU_ATTRIBUTE(aligned (8))
                                                  ^
      |
  226 | #define EI_(X)          extern StgWordArray (X) GNU_ATTRIBUTE(aligned (8))
      |                                              ^

  /tmp/ghc10489_0/ghc_3.hc:1754:6: error:
     note: previous definition of 'ghczmprim_GHCziTypes_zdtcTyCon2_bytes' was here
     char ghczmprim_GHCziTypes_zdtcTyCon2_bytes[] = "TyCon";
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       |
  1754 | char ghczmprim_GHCziTypes_zdtcTyCon2_bytes[] = "TyCon";
       |      ^

As we see here "_bytes" string literals are defined as 'char []'
array, not 'StgWord []'.

The change special-cases "_bytes" string literals to have
correct declaration type.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>