See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow

Trees that grow extension points are added for
- ValBinds
- HsPat
- HsLit
- HsOverLit
- HsType
- HsTyVarBndr
- HsAppType
- FieldOcc
- AmbiguousFieldOcc

Updates haddock submodule

Test Plan: ./validate

Reviewers: shayan-najd, simonpj, austin, goldfire, bgamari

Subscribers: goldfire, rwbarton, thomie, mpickering

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

Peter Trommler authored 7 years ago and Ben Gamari committed 7 years ago

Fixing #14244 required the newer gcc atomic built-ins that are provided
from 4.7 and up. This updates the test to check for minimum gcc version
4.7.

The version tests for 3.4 (!), 4.4, and 4.6 are no longer needed and can
be removed. This makes the build system simpler.

Test Plan: validate

Reviewers: austin, bgamari, hvr, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, erikd

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

This flag reintroduces the verbose module name output produced by GHCi's
:load command behind a new flag, -show-mods-loaded. This was originally
removed in D3651 but apparently some tools (e.g. haskell-mode) rely on
this output.

Addresses #14427.

Test Plan: Validate

Reviewers: svenpanne

Reviewed By: svenpanne

Subscribers: rwbarton, thomie

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

Reviewers: hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Douglas Wilson authored 7 years ago and Ben Gamari committed 7 years ago

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Ensure that we don't consider lists of equal length to be equal when
they are not. I noticed these while working on the fix for #14361.

Reviewers: austin, simonmar, michalt

Reviewed By: michalt

Subscribers: rwbarton, thomie

GHC Trac Issues: #14361

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Previously CBE computed equality by taking the lists of middle nodes of
the blocks being compared and zipping them together. It would then map
over this list with the equality relation, and accumulate the result.

However, this is completely wrong: Consider what will happen when we
compare a block with no middle nodes with one with one or more. The
result of `zip` will be empty and consequently the pass may conclude
that the two are indeed equivalent (if their last nodes also match).
This is very bad and the cause of #14361.

The solution I chose was just to write out an explicit recursion, like I
distinctly recall considering doing when I first wrote this code.
Unfortunately I was feeling clever at the time.

Unfortunately this case was just rare enough not to be triggered by the
testsuite. I still need to find a testcase that doesn't have external
dependencies.

Test Plan: Need to find a more minimal testcase

Reviewers: austin, simonmar, michalt

Reviewed By: michalt

Subscribers: michalt, rwbarton, thomie, hvr

GHC Trac Issues: #14361

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: Validate

Reviewers: Phyx, austin, erikd, simonmar

Reviewed By: Phyx

Subscribers: rwbarton, thomie

GHC Trac Issues: #14415

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

Previously, we could only deserialize `TypeRep (a -> b)` if
both `a` and `b` had kind `Type`. Now, we do it regardless of
their runtime representations.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Give `TypeRep` constructor fields names, and use them when pattern
matching and constructing values. This is a bit verbose, but makes
it obvious which field means what.

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Reviewers: austin, bgamari

Subscribers: rwbarton, thomie

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Earlier this year Edward Kmett requested [1] that we enable passing of
vector values in vector registers by default. The GHC calling convention
changes have been in LLVM for a number of years now so let's just flip
the switch.

[1] https://mail.haskell.org/pipermail/ghc-devs/2017-March/013905.html

Reviewers: austin

Subscribers: rwbarton, thomie

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

CmmProcs which have *lots* of local variables take a considerable
amount of time in CmmSink. This was noticed by @tdammers in #7258
while compiling files with large records (~200-400 fields).

Before:

```
        Sun Oct 29 19:58 2017 Time and Allocation Profiling Report (Final)

           ghc-stage2 +RTS -p -RTS
-B/Users/alexbiehl/git/ghc/inplace/lib /Users/alexbiehl/Downloads/W2.hs
-fforce-recomp -O2

        total time  =       26.00 secs   (25996 ticks @ 1000 us, 1 processor)
        total alloc = 14,921,627,912 bytes  (excludes profiling overheads)

COST CENTRE     MODULE      SRC %time %alloc

sink            CmmPipeline
compiler/cmm/CmmPipeline.hs:(104,13)-(105,59)        55.7   15.9
SimplTopBinds   SimplCore   compiler/simplCore/SimplCore.hs:761:39-74 19.5   30.6
FloatOutwards   SimplCore   compiler/simplCore/SimplCore.hs:471:40-66 4.2    9.0
RegAlloc-linear AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(658,27)-(660,55)    4.0   11.1
pprNativeCode   AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(529,37)-(530,65)    2.8    6.3
NewStranal      SimplCore   compiler/simplCore/SimplCore.hs:480:40-63 1.6    3.7
OccAnal         SimplCore compiler/simplCore/SimplCore.hs:(739,22)-(740,67)     1.5    3.5
StgCmm          HscMain compiler/main/HscMain.hs:(1426,13)-(1427,62)          1.2    2.4
regLiveness     AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(591,17)-(593,52)    1.2    1.9
genMachCode     AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(580,17)-(582,62)    0.9    1.8
NativeCodeGen   CodeOutput  compiler/main/CodeOutput.hs:171:18-78 0.9    2.1
CoreTidy        HscMain     compiler/main/HscMain.hs:1253:27-67 0.8    1.9
```

After:

```
        Sun Oct 29 19:18 2017 Time and Allocation Profiling Report (Final)

           ghc-stage2 +RTS -p -RTS
-B/Users/alexbiehl/git/ghc/inplace/lib /Users/alexbiehl/Downloads/W2.hs
-fforce-recomp -O2

        total time  =       13.31 secs   (13307 ticks @ 1000 us, 1 processor)
        total alloc = 15,772,184,488 bytes  (excludes profiling overheads)

COST CENTRE     MODULE         SRC %time %alloc

SimplTopBinds   SimplCore
compiler/simplCore/SimplCore.hs:761:39-74            38.3   29.0
sink            CmmPipeline compiler/cmm/CmmPipeline.hs:(104,13)-(105,59)        13.2   20.3
RegAlloc-linear AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(658,27)-(660,55)    8.3   10.5
FloatOutwards   SimplCore compiler/simplCore/SimplCore.hs:471:40-66             8.1    8.5
pprNativeCode   AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(529,37)-(530,65)    5.4    5.9
NewStranal      SimplCore compiler/simplCore/SimplCore.hs:480:40-63             3.1    3.5
OccAnal         SimplCore compiler/simplCore/SimplCore.hs:(739,22)-(740,67)     2.9    3.3
StgCmm          HscMain compiler/main/HscMain.hs:(1426,13)-(1427,62)          2.3    2.3
regLiveness     AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(591,17)-(593,52)    2.1    1.8
NativeCodeGen   CodeOutput     compiler/main/CodeOutput.hs:171:18-78 1.7    2.0
genMachCode     AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(580,17)-(582,62)    1.6    1.7
CoreTidy        HscMain        compiler/main/HscMain.hs:1253:27-67 1.4    1.8
foldNodesBwdOO  Hoopl.Dataflow compiler/cmm/Hoopl/Dataflow.hs:(397,1)-(403,17)       1.1    0.8
```

Reviewers: austin, bgamari, simonmar

Reviewed By: bgamari

Subscribers: duog, rwbarton, thomie, tdammers

GHC Trac Issues: #7258

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

Before the change UNREG ghc build failed as:
```
  rts_dist_HC rts/dist/build/PrimOps.o
/tmp/ghc2370_0/ghc_4.hc: In function 'stg_newByteArrayzh':

/tmp/ghc2370_0/ghc_4.hc:26:13: error:
     error: 'base_GHCziIOziException_heapOverflow_closure'
         undeclared (first use in this function)
     R1.w = (W_)&base_GHCziIOziException_heapOverflow_closure;
                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   |
26 | R1.w = (W_)&base_GHCziIOziException_heapOverflow_closure;
   |             ^
```

It's an UNREG-specific failure because C backend always requires
declarations to be known.

Added missing declaration.

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

Unfortunately this (ironically) ended up breaking bindist testing since
we didn't have a package-data.mk. Unfortunately there is no easy way to
fix this.

This reverts commit 1e9f90af.

Peter Trommler authored 7 years ago and Ben Gamari committed 7 years ago

In `libraries/ghc-prim/cbits/atomic.c` no barriers were issued for
atomic read and write operations. Starting with gcc 4.7 compiler
intrinsics are offered. The atomic intrinisics are also available in
clang. Use these to implement `hs_atomicread*` and `hs_atomicwrite`.

Test Plan: validate on OSX and Windows

Reviewers: austin, bgamari, simonmar, hvr, erikd, dfeuer

Reviewed By: bgamari

Subscribers: dfeuer, rwbarton, thomie

GHC Trac Issues: #14244

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

This breaks out control over STG free variable list output from
-dppr-debug into its own distinct flag. This makes it more discoverable
and easier to change independently from other dump output.

Test Plan: Validate

Reviewers: austin

Subscribers: rwbarton, thomie

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

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Reviewers: austin

Subscribers: rwbarton, thomie

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

Traditionally, `fixIO f` throws `BlockedIndefinitelyOnMVar` if
`f` is strict. This is not particularly friendly, since the
`MVar` in question is just part of the way `fixIO` happens to be
implemented. Instead, throw a new `FixIOException` with a better
explanation of the problem.

Reviewers: austin, hvr, bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #14356

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

I noticed this while tinkering in haddock. This might be a relict from
ancient times where newtypes wouldn't optimize well.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Implement hexadecmial floating point literals.

The digits of the mantissa are hexadecimal.
The exponent is written in base 10, and the base for the exponentiation is 2.
Hexadecimal literals look a lot like ordinary decimal literals, except that
they use hexadecmial digits, and the exponent is written using `p` rather than `e`.

The specification of the feature is available here:
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0004-hexFloats.rst

For a discussion of the various choices:
https://github.com/ghc-proposals/ghc-proposals/pull/37

Reviewers: mpickering, goldfire, austin, bgamari, hvr

Reviewed By: bgamari

Subscribers: mpickering, thomie

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

Peter Trommler authored 7 years ago and Ben Gamari committed 7 years ago

Implement AtomicRMW ops, atomic read, atomic write
in PowerPC native code generator. Also implement
branch prediction because we need it in atomic ops
anyway.

This patch improves the issue in #12537 a bit but
does not fix it entirely.

The fallback operations for atomicread and atomicwrite
in libraries/ghc-prim/cbits/atomic.c are incorrect.
This patch avoids those functions by implementing the
operations directly in the native code generator. This
is also what the x86/amd64 NCG and the LLVM backend
do.

Test Plan: validate on AIX and PowerPC (32-bit) Linux

Reviewers: erikd, hvr, austin, bgamari, simonmar

Reviewed By: hvr, bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #12537

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

This implements the `EmptyDataDeriving` proposal put forth in
https://github.com/ghc-proposals/ghc-proposals/blob/dbf51608/proposals/0006-deriving-empty.rst.
This has two major changes:

* The introduction of an `EmptyDataDeriving` extension, which
  permits directly deriving `Eq`, `Ord`, `Read`, and `Show` instances
  for empty data types.
* An overhaul in the code that is emitted in derived instances for
  empty data types. To see an overview of the changes brought forth,
  refer to the changes to the 8.4.1 release notes.

Test Plan: ./validate

Reviewers: bgamari, dfeuer, austin, hvr, goldfire

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #7401, #10577, #13117

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

This commit

  commit 85aa1f42
  Date:   Sun Oct 29 20:48:19 2017 -0400
    Fix #14390 by making toIfaceTyCon aware of equality

was a bit over-complicated. This patch simplifies the (horribly
ad-hoc) treatement of IfaceEqualityTyCon, and documents it better.

No visible change in behaviour.

and in comments