<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/haskell.git/utils, branch test</title>
<subtitle>gitlab.haskell.org: ghc/ghc.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/haskell.git/'/>
<entry>
<title>Bump version to 8.10.0</title>
<updated>2019-11-10T17:56:44+00:00</updated>
<author>
<name>Ben Gamari</name>
<email>ben@smart-cactus.org</email>
</author>
<published>2019-11-10T14:26:25+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/haskell.git/commit/?id=e86c495a220e077cbf56dbd59871b20616ea7124'/>
<id>e86c495a220e077cbf56dbd59871b20616ea7124</id>
<content type='text'>
Bumps haddock submodule.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Bumps haddock submodule.
</pre>
</div>
</content>
</entry>
<entry>
<title>Bump hsc2hs submodule</title>
<updated>2019-11-08T02:25:36+00:00</updated>
<author>
<name>Ben Gamari</name>
<email>ben@smart-cactus.org</email>
</author>
<published>2019-11-05T16:20:51+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/haskell.git/commit/?id=6b7d7e1c484cebe01014f4fa67abb48cacdd54f9'/>
<id>6b7d7e1c484cebe01014f4fa67abb48cacdd54f9</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>configure: Add checking python3-sphinx</title>
<updated>2019-11-06T13:06:37+00:00</updated>
<author>
<name>Takenobu Tani</name>
<email>takenobu.hs@gmail.com</email>
</author>
<published>2019-10-26T06:18:25+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/haskell.git/commit/?id=97f9674b59e65932737b978a201aaf24a0894ad3'/>
<id>97f9674b59e65932737b978a201aaf24a0894ad3</id>
<content type='text'>
This checks the configuration about python3-sphinx.
We need python3-sphinx instead of python2-sphinx to build documentation.

The approach is as follows:
* Check python3 version with custom `conf.py` invoked from
  sphinx-build` executable
* Place custom `conf.py` into new `utils/check-sphinx` directory

If sphinx is for python2 not python3, it's treated as config ERROR
instead of WARN.

See also #17346 and #17356.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This checks the configuration about python3-sphinx.
We need python3-sphinx instead of python2-sphinx to build documentation.

The approach is as follows:
* Check python3 version with custom `conf.py` invoked from
  sphinx-build` executable
* Place custom `conf.py` into new `utils/check-sphinx` directory

If sphinx is for python2 not python3, it's treated as config ERROR
instead of WARN.

See also #17346 and #17356.
</pre>
</div>
</content>
</entry>
<entry>
<title>Separate `LPat` from `Pat` on the type-level</title>
<updated>2019-11-03T00:16:33+00:00</updated>
<author>
<name>Sebastian Graf</name>
<email>sebastian.graf@kit.edu</email>
</author>
<published>2019-10-10T12:44:18+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/haskell.git/commit/?id=182b119943d34e82f67525c4b2390557f060c5f9'/>
<id>182b119943d34e82f67525c4b2390557f060c5f9</id>
<content type='text'>
Since the Trees That Grow effort started, we had `type LPat = Pat`.
This is so that `SrcLoc`s would only be annotated in GHC's AST, which is
the reason why all GHC passes use the extension constructor `XPat` to
attach source locations. See #15495 for the design discussion behind
that.

But now suddenly there are `XPat`s everywhere!
There are several functions which dont't cope with `XPat`s by either
crashing (`hsPatType`) or simply returning incorrect results
(`collectEvVarsPat`).

This issue was raised in #17330. I also came up with a rather clean and
type-safe solution to the problem: We define

```haskell
type family XRec p (f :: * -&gt; *) = r | r -&gt; p f
type instance XRec (GhcPass p) f = Located (f (GhcPass p))
type instance XRec TH          f =          f p
type LPat p = XRec p Pat
```

This is a rather modular embedding of the old "ping-pong" style, while
we only pay for the `Located` wrapper within GHC. No ping-ponging in
a potential Template Haskell AST, for example. Yet, we miss no case
where we should've handled a `SrcLoc`: `hsPatType` and
`collectEvVarsPat` are not callable at an `LPat`.

Also, this gets rid of one indirection in `Located` variants:
Previously, we'd have to go through `XPat` and `Located` to get from
`LPat` to the wrapped `Pat`. Now it's just `Located` again.

Thus we fix #17330.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since the Trees That Grow effort started, we had `type LPat = Pat`.
This is so that `SrcLoc`s would only be annotated in GHC's AST, which is
the reason why all GHC passes use the extension constructor `XPat` to
attach source locations. See #15495 for the design discussion behind
that.

But now suddenly there are `XPat`s everywhere!
There are several functions which dont't cope with `XPat`s by either
crashing (`hsPatType`) or simply returning incorrect results
(`collectEvVarsPat`).

This issue was raised in #17330. I also came up with a rather clean and
type-safe solution to the problem: We define

```haskell
type family XRec p (f :: * -&gt; *) = r | r -&gt; p f
type instance XRec (GhcPass p) f = Located (f (GhcPass p))
type instance XRec TH          f =          f p
type LPat p = XRec p Pat
```

This is a rather modular embedding of the old "ping-pong" style, while
we only pay for the `Located` wrapper within GHC. No ping-ponging in
a potential Template Haskell AST, for example. Yet, we miss no case
where we should've handled a `SrcLoc`: `hsPatType` and
`collectEvVarsPat` are not callable at an `LPat`.

Also, this gets rid of one indirection in `Located` variants:
Previously, we'd have to go through `XPat` and `Located` to get from
`LPat` to the wrapped `Pat`. Now it's just `Located` again.

Thus we fix #17330.
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "Replace freebsd-gnueabihf with freebsd"</title>
<updated>2019-10-29T07:50:06+00:00</updated>
<author>
<name>Ben Gamari</name>
<email>ben@smart-cactus.org</email>
</author>
<published>2019-10-27T15:49:57+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/haskell.git/commit/?id=72f7ac9ad66b886f4ea9569446e20aa4f97890e4'/>
<id>72f7ac9ad66b886f4ea9569446e20aa4f97890e4</id>
<content type='text'>
This reverts commit aa31ceaf7568802590f73a740ffbc8b800096342 as
suggested in #17392.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit aa31ceaf7568802590f73a740ffbc8b800096342 as
suggested in #17392.
</pre>
</div>
</content>
</entry>
<entry>
<title>Use FlexibleInstances for `Outputable (* p)` instead of match-all instances with equality constraints</title>
<updated>2019-10-28T13:22:35+00:00</updated>
<author>
<name>Sebastian Graf</name>
<email>sebastian.graf@kit.edu</email>
</author>
<published>2019-10-25T09:20:48+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/haskell.git/commit/?id=e951f219597a3e8209abd62f85c717865f7445ca'/>
<id>e951f219597a3e8209abd62f85c717865f7445ca</id>
<content type='text'>
In #17304, Richard and Simon dicovered that using `-XFlexibleInstances`
for `Outputable` instances of AST data types means users can provide orphan
`Outputable` instances for passes other than `GhcPass`.

Type inference doesn't currently to suffer, and Richard gave an example
in #17304 that shows how rare a case would be where the slightly worse
type inference would matter.

So I went ahead with the refactoring, attempting to fix #17304.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In #17304, Richard and Simon dicovered that using `-XFlexibleInstances`
for `Outputable` instances of AST data types means users can provide orphan
`Outputable` instances for passes other than `GhcPass`.

Type inference doesn't currently to suffer, and Richard gave an example
in #17304 that shows how rare a case would be where the slightly worse
type inference would matter.

So I went ahead with the refactoring, attempting to fix #17304.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge non-moving garbage collector</title>
<updated>2019-10-23T18:56:46+00:00</updated>
<author>
<name>Ben Gamari</name>
<email>ben@smart-cactus.org</email>
</author>
<published>2019-10-23T18:01:45+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/haskell.git/commit/?id=7f72b540288bbdb32a6750dd64b9d366501ed10c'/>
<id>7f72b540288bbdb32a6750dd64b9d366501ed10c</id>
<content type='text'>
This introduces a concurrent mark &amp; sweep garbage collector to manage the old
generation. The concurrent nature of this collector typically results in
significantly reduced maximum and mean pause times in applications with large
working sets.

Due to the large and intricate nature of the change I have opted to
preserve the fully-buildable history, including merge commits, which is
described in the "Branch overview" section below.

Collector design
================

The full design of the collector implemented here is described in detail
in a technical note

&gt; B. Gamari. "A Concurrent Garbage Collector For the Glasgow Haskell
&gt; Compiler" (2018)

This document can be requested from @bgamari.
The basic heap structure used in this design is heavily inspired by

&gt; K. Ueno &amp; A. Ohori. "A fully concurrent garbage collector for
&gt; functional programs on multicore processors." /ACM SIGPLAN Notices/
&gt; Vol. 51. No. 9 (presented at ICFP 2016)

This design is intended to allow both marking and sweeping
concurrent to execution of a multi-core mutator. Unlike the Ueno design,
which requires no global synchronization pauses, the collector
introduced here requires a stop-the-world pause at the beginning and end
of the mark phase.

To avoid heap fragmentation, the allocator consists of a number of
fixed-size /sub-allocators/. Each of these sub-allocators allocators into
its own set of /segments/, themselves allocated from the block
allocator. Each segment is broken into a set of fixed-size allocation
blocks (which back allocations) in addition to a bitmap (used to track
the liveness of blocks) and some additional metadata (used also used
to track liveness).

This heap structure enables collection via mark-and-sweep, which can be
performed concurrently via a snapshot-at-the-beginning scheme (although
concurrent collection is not implemented in this patch).

Implementation structure
========================

The majority of the collector is implemented in a handful of files:

 * `rts/Nonmoving.c` is the heart of the beast. It implements the entry-point
   to the nonmoving collector (`nonmoving_collect`), as well as the allocator
   (`nonmoving_allocate`) and a number of utilities for manipulating the heap.

 * `rts/NonmovingMark.c` implements the mark queue functionality, update
   remembered set, and mark loop.

 * `rts/NonmovingSweep.c` implements the sweep loop.

 * `rts/NonmovingScav.c` implements the logic necessary to scavenge the
   nonmoving heap.

Branch overview
===============

```
 * wip/gc/opt-pause:
 |   A variety of small optimisations to further reduce pause times.
 |
 * wip/gc/compact-nfdata:
 |   Introduce support for compact regions into the non-moving
 |\  collector
 | \
 |  \
 | | * wip/gc/segment-header-to-bdescr:
 | | |   Another optimization that we are considering, pushing
 | | |   some segment metadata into the segment descriptor for
 | | |   the sake of locality during mark
 | | |
 | * | wip/gc/shortcutting:
 | | |   Support for indirection shortcutting and the selector optimization
 | | |   in the non-moving heap.
 | | |
 * | | wip/gc/docs:
 | |/    Work on implementation documentation.
 | /
 |/
 * wip/gc/everything:
 |   A roll-up of everything below.
 |\
 | \
 | |\
 | | \
 | | * wip/gc/optimize:
 | | |   A variety of optimizations, primarily to the mark loop.
 | | |   Some of these are microoptimizations but a few are quite
 | | |   significant. In particular, the prefetch patches have
 | | |   produced a nontrivial improvement in mark performance.
 | | |
 | | * wip/gc/aging:
 | | |   Enable support for aging in major collections.
 | | |
 | * | wip/gc/test:
 | | |   Fix up the testsuite to more or less pass.
 | | |
 * | | wip/gc/instrumentation:
 | | |   A variety of runtime instrumentation including statistics
 | | /   support, the nonmoving census, and eventlog support.
 | |/
 | /
 |/
 * wip/gc/nonmoving-concurrent:
 |   The concurrent write barriers.
 |
 * wip/gc/nonmoving-nonconcurrent:
 |   The nonmoving collector without the write barriers necessary
 |   for concurrent collection.
 |
 * wip/gc/preparation:
 |   A merge of the various preparatory patches that aren't directly
 |   implementing the GC.
 |
 |
 * GHC HEAD
 .
 .
 .
```
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This introduces a concurrent mark &amp; sweep garbage collector to manage the old
generation. The concurrent nature of this collector typically results in
significantly reduced maximum and mean pause times in applications with large
working sets.

Due to the large and intricate nature of the change I have opted to
preserve the fully-buildable history, including merge commits, which is
described in the "Branch overview" section below.

Collector design
================

The full design of the collector implemented here is described in detail
in a technical note

&gt; B. Gamari. "A Concurrent Garbage Collector For the Glasgow Haskell
&gt; Compiler" (2018)

This document can be requested from @bgamari.
The basic heap structure used in this design is heavily inspired by

&gt; K. Ueno &amp; A. Ohori. "A fully concurrent garbage collector for
&gt; functional programs on multicore processors." /ACM SIGPLAN Notices/
&gt; Vol. 51. No. 9 (presented at ICFP 2016)

This design is intended to allow both marking and sweeping
concurrent to execution of a multi-core mutator. Unlike the Ueno design,
which requires no global synchronization pauses, the collector
introduced here requires a stop-the-world pause at the beginning and end
of the mark phase.

To avoid heap fragmentation, the allocator consists of a number of
fixed-size /sub-allocators/. Each of these sub-allocators allocators into
its own set of /segments/, themselves allocated from the block
allocator. Each segment is broken into a set of fixed-size allocation
blocks (which back allocations) in addition to a bitmap (used to track
the liveness of blocks) and some additional metadata (used also used
to track liveness).

This heap structure enables collection via mark-and-sweep, which can be
performed concurrently via a snapshot-at-the-beginning scheme (although
concurrent collection is not implemented in this patch).

Implementation structure
========================

The majority of the collector is implemented in a handful of files:

 * `rts/Nonmoving.c` is the heart of the beast. It implements the entry-point
   to the nonmoving collector (`nonmoving_collect`), as well as the allocator
   (`nonmoving_allocate`) and a number of utilities for manipulating the heap.

 * `rts/NonmovingMark.c` implements the mark queue functionality, update
   remembered set, and mark loop.

 * `rts/NonmovingSweep.c` implements the sweep loop.

 * `rts/NonmovingScav.c` implements the logic necessary to scavenge the
   nonmoving heap.

Branch overview
===============

```
 * wip/gc/opt-pause:
 |   A variety of small optimisations to further reduce pause times.
 |
 * wip/gc/compact-nfdata:
 |   Introduce support for compact regions into the non-moving
 |\  collector
 | \
 |  \
 | | * wip/gc/segment-header-to-bdescr:
 | | |   Another optimization that we are considering, pushing
 | | |   some segment metadata into the segment descriptor for
 | | |   the sake of locality during mark
 | | |
 | * | wip/gc/shortcutting:
 | | |   Support for indirection shortcutting and the selector optimization
 | | |   in the non-moving heap.
 | | |
 * | | wip/gc/docs:
 | |/    Work on implementation documentation.
 | /
 |/
 * wip/gc/everything:
 |   A roll-up of everything below.
 |\
 | \
 | |\
 | | \
 | | * wip/gc/optimize:
 | | |   A variety of optimizations, primarily to the mark loop.
 | | |   Some of these are microoptimizations but a few are quite
 | | |   significant. In particular, the prefetch patches have
 | | |   produced a nontrivial improvement in mark performance.
 | | |
 | | * wip/gc/aging:
 | | |   Enable support for aging in major collections.
 | | |
 | * | wip/gc/test:
 | | |   Fix up the testsuite to more or less pass.
 | | |
 * | | wip/gc/instrumentation:
 | | |   A variety of runtime instrumentation including statistics
 | | /   support, the nonmoving census, and eventlog support.
 | |/
 | /
 |/
 * wip/gc/nonmoving-concurrent:
 |   The concurrent write barriers.
 |
 * wip/gc/nonmoving-nonconcurrent:
 |   The nonmoving collector without the write barriers necessary
 |   for concurrent collection.
 |
 * wip/gc/preparation:
 |   A merge of the various preparatory patches that aren't directly
 |   implementing the GC.
 |
 |
 * GHC HEAD
 .
 .
 .
```
</pre>
</div>
</content>
</entry>
<entry>
<title>Make dynflag argument for withTiming pure.</title>
<updated>2019-10-23T09:59:04+00:00</updated>
<author>
<name>Andreas Klebinger</name>
<email>klebinger.andreas@gmx.at</email>
</author>
<published>2019-10-20T00:30:01+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/haskell.git/commit/?id=6beea836094383eea96b15e526f31b5426aea630'/>
<id>6beea836094383eea96b15e526f31b5426aea630</id>
<content type='text'>
19 times out of 20 we already have dynflags in scope.

We could just always use `return dflags`. But this is in fact not free.
When looking at some STG code I noticed that we always allocate a
closure for this expression in the heap. Clearly a waste in these cases.

For the other cases we can either just modify the callsite to
get dynflags or use the _D variants of withTiming I added which
will use getDynFlags under the hood.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
19 times out of 20 we already have dynflags in scope.

We could just always use `return dflags`. But this is in fact not free.
When looking at some STG code I noticed that we always allocate a
closure for this expression in the heap. Clearly a waste in these cases.

For the other cases we can either just modify the callsite to
get dynflags or use the _D variants of withTiming I added which
will use getDynFlags under the hood.
</pre>
</div>
</content>
</entry>
<entry>
<title>Implement s390x LLVM backend.</title>
<updated>2019-10-22T06:39:03+00:00</updated>
<author>
<name>Stefan Schulze Frielinghaus</name>
<email>stefansf@linux.ibm.com</email>
</author>
<published>2019-10-08T10:32:15+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/haskell.git/commit/?id=fd8b666acfee5524a2d7c8b845a3782f6a89bec7'/>
<id>fd8b666acfee5524a2d7c8b845a3782f6a89bec7</id>
<content type='text'>
This patch adds support for the s390x architecture for the LLVM code
generator. The patch includes a register mapping of STG registers onto
s390x machine registers which enables a registerised build.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch adds support for the s390x architecture for the LLVM code
generator. The patch includes a register mapping of STG registers onto
s390x machine registers which enables a registerised build.
</pre>
</div>
</content>
</entry>
<entry>
<title>Replace freebsd-gnueabihf with freebsd</title>
<updated>2019-10-22T06:39:01+00:00</updated>
<author>
<name>Matthew Bauer</name>
<email>mjbauer95@gmail.com</email>
</author>
<published>2019-09-25T15:25:25+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/haskell.git/commit/?id=aa31ceaf7568802590f73a740ffbc8b800096342'/>
<id>aa31ceaf7568802590f73a740ffbc8b800096342</id>
<content type='text'>
FreeBSD does not support GNU libc, so it makes no sense to use this
triple. Most likely previous builds were just using the FreeBSD libc
instead of gnueabihf. To fix this, we should just use
armv6-unknown-freebsd and armv7-unknown-freebsd triples. Note that
both of these are actually "soft-float", not "hard-float". FreeBSD has
never officially released hard-float arm32:

https://wiki.freebsd.org/ARMTier1
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
FreeBSD does not support GNU libc, so it makes no sense to use this
triple. Most likely previous builds were just using the FreeBSD libc
instead of gnueabihf. To fix this, we should just use
armv6-unknown-freebsd and armv7-unknown-freebsd triples. Note that
both of these are actually "soft-float", not "hard-float". FreeBSD has
never officially released hard-float arm32:

https://wiki.freebsd.org/ARMTier1
</pre>
</div>
</content>
</entry>
</feed>
