GitLab

This was failing on Darwin; I believe this is due to 33de71fa.

This patch made the simplifier inline nested function bindings less aggressively
and, while it didn't seem to affect nofib, appears to have regressed T9630
rather considerably.

This commit bumped T12425, T12234 and T12150 over their expected metrics on OS
X.

Tobias Dammers authored Apr 20, 2018 and Ben Gamari committed Apr 20, 2018

The coercion optimizer will take care of it anyway, and the check is
prohibitively expensive.

See Trac #14737.

Reviewers: bgamari

Subscribers: simonpj, thomie, carter

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

Tobias Dammers authored Apr 20, 2018 and Ben Gamari committed Apr 20, 2018

While addressing nonlinear behavior related to coercion roles,
particularly `NthCo`, we noticed that coercion roles are recalculated
often even though they should be readily at hand already in most cases.
This patch adds a `Role` to the `NthCo` constructor so that we can cache
them rather than having to recalculate them on the fly.
https://ghc.haskell.org/trac/ghc/ticket/11735#comment:23 explains the
approach.

Performance improvement over GHC HEAD, when compiling Grammar.hs (see below):

GHC 8.2.1:
```
ghc Grammar.hs  176.27s user 0.23s system 99% cpu 2:56.81 total
```

before patch (but with other optimizations applied):
```
ghc Grammar.hs -fforce-recomp  175.77s user 0.19s system 100% cpu 2:55.78 total
```

after:
```
../../ghc/inplace/bin/ghc-stage2 Grammar.hs  10.32s user 0.17s system 98% cpu 10.678 total
```

Introduces the following regressions:

- perf/compiler/parsing001 (possibly false positive)
- perf/compiler/T9872
- perf/compil...

This patch, authored by alexvieth and reviewed at D4451,
makes performance improvements by critically optimizing parts
of the flattener.

Summary:
T3064, T5321FD, T5321Fun, T9872a, T9872b, T9872c all pass.
T9872a and T9872c show improvements beyond the -5% threshold.
T9872d fails at 10.9% increased allocations.

Before this change we would compute a hash of
all the command line -optP flags once per file.
With a lot of files and many -optP flags, that's a lot
of repeated work.

I added a new Note that explains the approach and rationale.

Test Plan: new test

Reviewers: simonmar, simonpj, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14697

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

This reverts commit d675a354.

I'm not sure why. It's an odd test, mind you; a weird type-function
recursion thing.  So I'm not inclined to investigate.

Anyway, good!

Sadly it's not immediately obvious where this regression came from:

 * T5837 started failing on OS X with 0c2350c2
 * It's not clear when T1969 started failing due to the recent out of memory
   issues on Harbormaster

There's a 6% reduction in allocation on T3064.  I think it's due to

  commit e4ab65bd
  Author: Tobias Dammers <tdammers@gmail.com>
  Date:   Wed Jan 31 21:39:45 2018 -0500

      Optimize coercionKind (Trac #11735)

I'm not certain -- but, hey, it's good news

takano-akio authored Jan 31, 2018 and Ben Gamari committed Jan 31, 2018

This patch implements the BlockArguments extension, as proposed at
https://github.com/ghc-proposals/ghc-proposals/pull/90. It also
fixes #10855 as a side-effect.

This patch adds a large number of shift-reduce conflicts to the parser.
All of them concern the ambiguity as to where constructs like `if` and
`let` end. Fortunately they are resolved correctly by preferring shift.

The patch is based on @gibiansky's ArgumentDo implementation (D1219).

Test Plan: ./validate

Reviewers: goldfire, bgamari, alanz, mpickering

Reviewed By: bgamari, mpickering

Subscribers: Wizek, dfeuer, gibiansky, rwbarton, thomie, mpickering, carter

GHC Trac Issues: #10843, #10855

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

Ideally, I'd like to do

    type EvTerm = CoreExpr

and the type checker builds the evidence terms as it goes. This failed,
becuase the evidence for `Typeable` refers to local identifiers that are
added *after* the typechecker solves constraints. Therefore, `EvTerm`
stays a data type with two constructors: `EvExpr` for `CoreExpr`
evidence, and `EvTypeable` for the others.

Delted `Note [Memoising typeOf]`, its reference (and presumably
relevance) was removed in 8fa4bf9a.

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

This gives a 10% allocation improvement on MultiLayerModules.
The idea is to reuse existing tuples, instead of constantly
constructing new ones.

Test Plan: ./validate

Reviewers: simonpj, bgamari

Reviewed By: simonpj, bgamari

Subscribers: rwbarton, thomie, simonmar, carter

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

niteria authored Jan 21, 2018 and Ben Gamari committed Jan 21, 2018

Before this change, a list was used as a substitute for a heap.
This led to quadratic behavior on a simple program (see new
test case).

This change replaces it with IntSet in effect reverting
5a1a2633. @simonmar said it's fine to revert as long as nofib
results are good.

Test Plan:
new test case:

20% improvement
3x improvement when N=10000

nofib:

I run it twice for before and after because the compile time
results are noisy.

- Compile Allocations:

```
          before    before re-run    after     after re-run
-1 s.d.   -----     -0.0%            -0.1%     -0.1%
+1 s.d.   -----     +0.0%            +0.1%     +0.1%
Average   -----     +0.0%            -0.0%     -0.0%
```
- Compile Time:

```
          before    before re-run    after     after re-run
-1 s.d.   -----     -0.1%            -2.3%     -2.6%
+1 s.d.   -----     +5.2%            +3.7%     +4.4%
Average   -----     +2.5%            +0.7%     +0.8%

```
I checked each case and couldn't find consistent slow-down/speed-up on
compile time. Full results here: P173

Reviewers: simonpj, simonmar, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter, simonmar

GHC Trac Issues: #14667

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

Before this change, for each constructor that we want
to allocate a tag for we would traverse a list of all
the constructors in a datatype to determine which tag
a constructor should get.

This is obviously quadratic and for datatypes with 10k
constructors it actually makes a big difference.

This change implements the plan outlined by @simonpj in
https://mail.haskell.org/pipermail/ghc-devs/2017-October/014974.html
which is basically about using a map and constructing it outside the
loop.

One place where things got a bit awkward was TysWiredIn.hs,
it would have been possible to just assign the tags by hand, but
that seemed error-prone to me, so I decided to go through a map
there as well.

Test Plan:
./validate
On a file with 10k constructors
Before:
   8,130,522,344 bytes allocated in the heap
  Total   time    3.682s  (  3.920s elapsed)
After:
   4,133,478,744 bytes allocated in the heap
  Total   time    2.509s  (  2.750s elapsed)

Reviewers: simonpj, bgamari

Reviewed By: simonpj

Subscribers: goldfire, rwbarton, thomie, simonmar, carter, simonpj

GHC Trac Issues: #14657

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

Trac #13032 pointed out that we sometimes generate unused
bindings for Givens, and (worse still) we can't always discard
them later (we don't drop a case binding unless we can prove
that the scrutinee is non-bottom.

It looks as if this may be a major reason for the performace
problems in #14338 (see comment:29).

This patch fixes the problem at source, by pruning away all the
dead Givens.  See Note [Delete dead Given evidence bindings]

Remarkably, compiler allocation falls by 23% in
perf/compiler/T12227!

I have not confirmed whether this change actualy helps with

Tamar Christina authored Jan 02, 2018 and Ben Gamari committed Jan 02, 2018

This makes the testsuite pass clean on Windows again.
It also fixes the `libstdc++-6.dll` error harbormaster
was showing.

I'm marking some tests as isolated tests to reduce their
flakiness (mostly concurrency tests) when the test system
is under heavy load.

Updates process submodule.

Test Plan: ./validate

Reviewers: hvr, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

Bytes allocated has fallen by around 5%. I think this due
to some of my recent refactoring of the typechecker, but
I'm not certain about exactly which change did it.

Good though!

Tobias Dammers authored Oct 25, 2017 and Ben Gamari committed Oct 25, 2017

Improves compiler performance of deriving Read instances, as suggested
in the issue.

Additionally, we introduce `readSymField`, a companion to `readField`
that parses symbol-type fields (where the field name is a symbol, e.g.
`(#)`, rather than an alphanumeric identifier. The decision between
these two functions is made a compile time, because we already know
which one we need based on the field name.

Reviewers: austin, hvr, bgamari, RyanGlScott

Reviewed By: bgamari

Subscribers: RyanGlScott, rwbarton, thomie

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

Douglas Wilson authored Oct 25, 2017 and Ben Gamari committed Oct 25, 2017

Replace a call to mapAccumR, which uses linear stack space, with a
gadget that uses constant space.

Remove an unused parameter from fromOnDiskName.

The tests T1292_imports and T4239 are now reporting imported names in a
different order. I don't completely understand why, but I presume it is
because the symbol tables are now read more strictly. The new order
seems better in T1792_imports, and equally random in T4239.

There are several performance test improvements.

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: alexbiehl, rwbarton, thomie

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

It looks like this is probably just drift.

Unfortunately, this requires introducing a couple of .hs-boot files to
break up import cycles (mostly to provide class & typenames in order to
be able to write type signatures).

This does not yet re-export `(<>)` from Prelude (while the class-name
`Semigroup` is reexported); that will happen in a future commit.

Test Plan: local ./validate passed

Reviewers: ekmett, austin, bgamari, erikd, RyanGlScott

Reviewed By: ekmett, RyanGlScott

GHC Trac Issues: #14191

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

Moritz Angermann authored Sep 06, 2017 and Ben Gamari committed Sep 06, 2017

The LLVM backend shells out to LLVMs `opt` and `llc` tools. This clean
up introduces a shared data structure to carry the arguments we pass to
each tool so that corresponding flags are next to each other. It drops
the hard coded data layouts in favor of using `-mtriple` and have LLVM
infer them. Furthermore we add `clang` as a proper tool, so we don't
rely on assuming that `clang` is called `clang` on the `PATH` when using
`clang` as the assembler.  Finally this diff also changes the type of
`optLevel` from `Int` to `Word`, as we do not have negative optimization
levels.

Reviewers: erikd, hvr, austin, rwbarton, bgamari, kavon

Reviewed By: kavon

Subscribers: michalt, Ericson2314, ryantrinkle, dfeuer, carter, simonpj,
kavon, simonmar, thomie, erikd, snowleopard

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

T1969 and T12150 were failing (stat too high)

Triggered by #12150, and the knock-on effects of join points, I did a
major refactoring of the Simplifier.  This is a big patch that change
a lot of Simplify.hs: I did a lot of other re-organisation.

The main event
~~~~~~~~~~~~~~
Since the dawn of time we have had
  simplExpr :: SimplEnv -> InExpr -> SimplCont
            -> SimplM (SimplEnv, OutExpr)

What's that SimplEnv in the result?  When simplifying an expression the
simplifier add floated let-bindings to the SimplEnv, extending the
in-scope set appropriately, and hence needs to resturn the SimplEnv at
the end.  The mode, flags, substitution in the returned SimplEnv were
all irrelevant: it was just the floating bindings.

It's strange to accumulate part of the /result/ in the /environment/
argument!  And indeed its leads to all manner of mysterious calls to
zapFloats and transferring of floats from one SimplEnv to another.
It got worse with join points, so I finally bit the bullet and refactored.
Now we have
  simplExpr :: SimplEnv -> InExpr -> SimplCont
            -> SimplM (SimplFloats, OutExpr)
  -- See Note [The big picture]
and the SimplEnv no longer has floats in it.  The code is no shorter,
but it /is/ easier to understand.

Main changes

* Remove seLetFloats field from SimplEnv

* Define new data type SimplFloats, and functions over it

* Change the types of simplExpr, simplBind, and their many variants,
  to follow the above plan

Bottoming bindings
~~~~~~~~~~~~~~~~~~
I made one other significant change in SimplUtils (not just refactoring),
related to Trac #12150 comment:16.  Given
  x = <rhs>
where <rhs> turns out to be a bottoming expression, propagate that
information to x's IdInfo immediately.  That's always good, because
it makes x be inlined less (we don't inline bottoming things), and
it allows (case x of ...) to drop the dead alterantives immediately.
Moreover, we are doing the analysis anyway, in tryEtaExpandRhs, which
calls CoreArity.findRhsArity, which already does simple bottom analysis.
So we are generating the information; all we need do is to atach the
bottoming info to the IdInfo.

See Note [Bottoming bindings]

Smaller refactoring
~~~~~~~~~~~~~~~~~~~
* Rename SimplifierMode to SimplMode
* Put DynFlags as a new field in SimplMode, to make fewer
  monadic calls to getDynFlags.
* Move the code in addPolyBind into abstractFloats
* Move the "don't eta-expand join points" into tryEtaExpandRhs

A type equality error can arise from a mismatch between
*invisible* arguments just as easily as from visible arguments.
But we should really prefer printing out errors from visible
arguments over invisible ones. Suppose we have a mismatch between
`Proxy Int` and `Proxy Maybe`. Would you rather get an error
between `Int` and `Maybe`? Or between `*` and `* -> *`? I thought
so, too.

There is a fair amount of plumbing with this one, but I think
it's worth it.

This commit introduces a performance regression in test
perf/compiler/T5631. The cause of the regression is not the
new visibility stuff, directly: it's due to a change from
zipWithM to zipWith3M in TcUnify. To my surprise, zipWithM
is nicely optimized (it fuses away), but zipWith3M is not.
There are other examples of functions that could be made faster,
so I've posted a separate ticket, #14037, to track these
improvements. For now, I've accepted the small (6.6%) regression.

Douglas Wilson authored Jul 20, 2017 and Ben Gamari committed Jul 20, 2017

Test T13701 was failing sporadically. The problem manifested while the
test was run on a system under load. Profiling showed the increased
allocations were in SysTools.builderMainLoop.loop, during calls to the
assembler. This was due to loop effectively busy-waiting from when both
stdin and stderr handles were closed, until getProcessExitCode
succeeded.

This is fixed by removing exit code handling from loop. We now wait for
loop to finish, then read the exit code with waitForProcess.

Some exception safety is added: the readerProc threads will now be
killed and the handles will be closed if an exception is thrown.

A TODO saying that threads dying is not accounted for is removed. I
believe that this case is handled by readerProc sending EOF in a finally
clause.

Test Plan:
Replicate test failures using procedure on the ticket, verify that they
do not occur with this patch.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13987

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

Ben Gamari authored Jul 19, 2017 and Ben Gamari committed Jul 19, 2017

This fixes #13915, where the promoted tycons belonging to data family
instances wouldn't get Typeable bindings, resulting in missing
declarations.

Test Plan: Validate with included testcases

Reviewers: austin, simonpj

Reviewed By: simonpj

Subscribers: simonpj, RyanGlScott, rwbarton, thomie

GHC Trac Issues: #13915

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

This test appears to be quite unstable.

David Feuer authored Jun 29, 2017 and Ben Gamari committed Jun 29, 2017

For some reason, this test seems to allocate rather more under
Linux than under OSX or Windows.

Reviewers: austin, bgamari

Subscribers: rwbarton, thomie

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

Ben Gamari authored Jun 27, 2017 and Ben Gamari committed Jun 27, 2017

This is another attempt at resolving #13594 by treating strict variable
binds as FunBinds instead of PatBinds (as suggested in comment:1).

Test Plan: Validate

Reviewers: austin, alanz

Subscribers: rwbarton, thomie, mpickering

GHC Trac Issues: #13594

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

Michal Terepeta authored Jun 18, 2017 and Ben Gamari committed Jun 19, 2017

This tries to be more precise when generating reloads of local
registers in proc points. Previously we'd reload all local registers
that were live. But we used liveness information that assumed local
registers survive native calls. For the purpose of reloading registers
this is an overapproximation and might lead to generating huge amounts
of unnecessary reloads (in case there's another proc point before the
register is used).

This change takes the approach of moving the generation of reloads to
a second pass over the Cmm, which allows to recompute the liveness and
can use the knowledge that local registers do *not* survive calls.
This leads to generating only useful reloads. For an extreme example
where this helps a lot please see T3294. This should also fix #7198



Finally, this re-introduces the code to do Cmm rewriting using in
`Dataflow` module (with the difference that we know operate on a whole
block at a time).
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Reviewers: austin, bgamari, simonmar

Reviewed By: simonmar

Subscribers: kavon, rwbarton, thomie

GHC Trac Issues: #7198

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

David Feuer authored Jun 18, 2017 and Ben Gamari committed Jun 19, 2017

This is not the most precise test, unfortunately, but it does
demonstrate a modest improvement in compiler residency as a
result of the specializer don't-loop patch. A rather less
realistic variation on this has somewhat more dramatic effects.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

Ryan Scott authored Jun 12, 2017 and Ben Gamari committed Jun 12, 2017

Commit 2b74bd9d did wonders for the
program reported in #12545. Let's add a perf test for it to make sure it
stays fast.

Test Plan: make test TEST=T12545

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #12545

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