| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverses some of the work done in Trac #1405, and assumes GHC is
smart enough to do its own unboxing of booleans now.
I would like to do some more performance measurements, but the code
changes can be reviewed already.
Test Plan:
With a perf build:
./inplace/bin/ghc-stage2 nofib/spectral/simple/Main.hs -fforce-recomp
+RTS -t --machine-readable
before:
```
[("bytes allocated", "1300744864")
,("num_GCs", "302")
,("average_bytes_used", "8811118")
,("max_bytes_used", "24477464")
,("num_byte_usage_samples", "9")
,("peak_megabytes_allocated", "64")
,("init_cpu_seconds", "0.001")
,("init_wall_seconds", "0.001")
,("mutator_cpu_seconds", "2.833")
,("mutator_wall_seconds", "4.283")
,("GC_cpu_seconds", "0.960")
,("GC_wall_seconds", "0.961")
]
```
after:
```
[("bytes allocated", "1301088064")
,("num_GCs", "310")
,("average_bytes_used", "8820253")
,("max_bytes_used", "24539904")
,("num_byte_usage_samples", "9")
,("peak_megabytes_allocated", "64")
,("init_cpu_seconds", "0.001")
,("init_wall_seconds", "0.001")
,("mutator_cpu_seconds", "2.876")
,("mutator_wall_seconds", "4.474")
,("GC_cpu_seconds", "0.965")
,("GC_wall_seconds", "0.979")
]
```
CPU time seems to be up a bit, but I'm not sure. Unfortunately CPU time
measurements are rather noisy.
Reviewers: austin, bgamari, rwbarton
Subscribers: nomeata
Differential Revision: https://phabricator.haskell.org/D1143
GHC Trac Issues: #1405
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the PowerPC 32-bit native code generator for "64-bit
PowerPC ELF Application Binary Interface Supplement 1.9" by
Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification --
OpenPOWER ABI for Linux Supplement" by IBM.
The latter ABI is mainly used on POWER7/7+ and POWER8
Linux systems running in little-endian mode. The code generator
supports both static and dynamic linking. PowerPC 64-bit
code for ELF ABI 1.9 and 2 is mostly position independent
anyway, and thus so is all the code emitted by the code
generator. In other words, -fPIC does not make a difference.
rts/stg/SMP.h support is implemented.
Following the spirit of the introductory comment in
PPC/CodeGen.hs, the rest of the code is a straightforward
extension of the 32-bit implementation.
Limitations:
* Code is generated only in the medium code model, which
is also gcc's default
* Local symbols are not accessed directly, which seems to
also be the case for 32-bit
* LLVM does not work, but this does not work on 32-bit either
* Must use the system runtime linker in GHCi, because the
GHC linker for "static" object files (rts/Linker.c) for
PPC 64-bit is not implemented. The system runtime
(dynamic) linker works.
* The handling of the system stack (register 1) is not ELF-
compliant so stack traces break. Instead of allocating a new
stack frame, spill code should use the "official" spill area
in the current stack frame and deallocation code should restore
the back chain
* DWARF support is missing
Fixes #9863
Test Plan: validate (on powerpc, too)
Reviewers: simonmar, trofi, erikd, austin
Reviewed By: trofi
Subscribers: bgamari, arnons1, kgardas, thomie
Differential Revision: https://phabricator.haskell.org/D629
GHC Trac Issues: #9863
|
