Thanks, I forgot to follow up that I updated the Fedora ghc:8.8 module stream to alpha2 for F30+. Though it fails sometimes on s390x (gcc failure).

That is true and this will be fixed for the release candidate. However Debian 8 is now no longer Debian's current stable release so I wasn't prioritizing this issue. If the lack of a Debian 8 distribution is preventing anyone from testing please let me know. Cheers, - Ben On June 17, 2019 6:24:16 AM EDT, Matthew Pickering wrote:

There seems to be no debian8 bindist which is different from every release at least back to ghc-8.0.1.

On Sat, Jun 15, 2019 at 8:36 PM Ben Gamari wrote:

...

Hello everyone,

The GHC team is pleased to announce the second and likely last alpha release of GHC 8.8.1. The source distribution, binary distributions,

...

documentation are available at

https://downloads.haskell.org/~ghc/8.8.1-alpha2

A draft of the release notes is also available [1].

This release is the culmination of over 3000 commits by over one hundred contributors and has several new features and numerous bug fixes relative to GHC 8.6:

* Profiling now works correctly on 64-bit Windows (although still may be problematic on 32-bit Windows due to platform limitations; see #15934)

* A new code layout algorithm for amd64's native code generator

* The introduction of a late lambda-lifting pass which may reduce allocations significantly for some programs.

* Further work on Trees That Grow, enabling improved code re-use of

...

Haskell AST in tooling

* More locations where users can write `forall` (GHC Proposal #0007)

* Further work on the Hadrian build system

This release brings a number of fixes since alpha 1:

* A number of linker fixes (#16779, #16784)

* The process, binary, Cabal, time, terminfo libraries have all been bumped to their final release versions

* A regression rendering TemplateHaskell unusable in cross-compiled configurations has been fixed (#16331)

* A regression causing compiler panics on compilation of some

and the programs

...

has been fixed (#16449)

* -Wmissing-home-modules now handles hs-boot files correctly (#16551)

* A regression causing some programs to fail at runtime has been fixed (#16066)

Due to on-going work on our release and testing infrastructure this cycle is proceeding at a pace significantly slower than expected. However, we anticipate that this investment will allow us to release a more reliable, easier-to-install compiler on the planned six-month release cadence in the future.

As always, if anything looks amiss do let us know.

Happy compiling!

Cheers,

- Ben

[1] https://downloads.haskell.org/ghc/8.8.1-alpha2/docs/html/users_guide/8.8.1-n... _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Karel Gardas writes:

Hi Ben,

On 06/15/19 09:35 PM, Ben Gamari wrote:

...

Hello everyone,

The GHC team is pleased to announce the second and likely last alpha release of GHC 8.8.1. The source distribution, binary distributions, and documentation are available at

https://downloads.haskell.org/~ghc/8.8.1-alpha2

A draft of the release notes is also available [1].

No sure why, but fix for #13633 has not made into the 8.8 branch. Due to this testwsdeque fails from time to time on POWER. Tested on ppc64le/ubuntu 18.04. Bootstrapped with ghc 8.6.3.

Is there any chance you may cherrypick Peter's fix in merge request 445? Would be great since otherwise besides some profiling related tests failing the build looks fine on ppc64le.

Thanks Karel! I've cherry-picked this and there will be an additional set of memory ordering fixes [1] appearing in 8.8 as well. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/1128/

George Colpitts writes:

Will 8.8.1 use llvm 7.0.1? I don't see it mentioned in the release notes.

Yes, this release will target LLVM 7. I'll add a mention to the release notes. Cheers, - Ben

Yes, callbr is part of the discussion on removing proc-point splitting! Soon there will be an announcement about a new working group dedicated to LLVM issues such as this one on this mailing list. Anyone interested is welcome to join our meetings. We're currently gathering our notes together first, but you can have a look here for a preview: https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/LLVM-Backend-Op... On Sun, 2019-06-23 at 12:00 -0300, George Colpitts wrote:

Hi

I hope this question isn't too dumb. llvm has a new callbr instruction to implement asm-goto http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Asm-Goto-Merged Could this be used to avoid proc-point splitting?

Thanks George

_______________________________________________ghc-devs mailing listghc- devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Kavon Farvardin writes:

Yes, callbr is part of the discussion on removing proc-point splitting! Soon there will be an announcement about a new working group dedicated to LLVM issues such as this one on this mailing list. Anyone interested is welcome to join our meetings. We're currently gathering our notes together first, but you can have a look here for a preview: https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/LLVM-Backend-Op...

Hi Kavon, What ever happened to this? It came up during the GHC call and we realized that none of us knew what the state of the proposal was. Is this Wiki page still reflective of the current state of play? Cheers, - Ben

Thanks Kavon. What news of CpsCall in LLVM? That seems crucial. I didn’t know of an effort to use a different SP register. I seriously doubt that, with GHC’s use of zillions of small, heap-allocated stacks that move around during GHC, we’ll be able to leverage profiling or debugging tools in a serious way. But perhaps I need education. Simon From: ghc-devs On Behalf Of Kavon Farvardin Sent: 04 December 2019 19:32 To: Ben Gamari Cc: GHC developers Subject: Re: new llvm IR callbr instruction useful for proc-point splitting? Hi Ben, The Wiki now has a link to the Google Doc that Michal and I were working on to compile all of the notes into one place. The key progress made on this front has been in evaluating the trade-offs of the design space being considered by GHC, but tested within Manticore. I'm drafting a message today for the LLVM mailing list regarding one of our first options: defining a GHC ABI to redefine which stack-pointer register is used. Once we have additional answers to the question "how much effort is it to add a GHC ABI to LLVM?", we can then then start a discussion on whether GHC wants to change instead by moving to a native stack-pointer register (to take advantage of existing debugging and profiling tools, etc). Ideally, we would then make a decision on which option to take and someone (perhaps a GSoC student with mentorship from myself and others) with spare time can work on it. Cheers, Kavon On Wed, 2019-12-04 at 11:38 -0500, Ben Gamari wrote: Kavon Farvardin mailto:kavon@farvard.in> writes: Yes, callbr is part of the discussion on removing proc-point splitting! Soon there will be an announcement about a new working group dedicated to LLVM issues such as this one on this mailing list. Anyone interested is welcome to join our meetings. We're currently gathering our notes together first, but you can have a look here for a preview: https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/LLVM-Backend-Op... Hi Kavon, What ever happened to this? It came up during the GHC call and we realized that none of us knew what the state of the proposal was. Is this Wiki page still reflective of the current state of play? Cheers, - Ben

On Wed, 2019-12-04 at 22:16 +0000, Simon Peyton Jones wrote:

Thanks Kavon.

What news of CpsCall in LLVM? That seems crucial.

CPSCall is in essence equivalent to an existing construct in LLVM for GC support called "statepoints." The difference is that CPSCall expects the front-end to allocate the stack frame, whereas statepoints are hooked into LLVM's stack- allocation infrastructure. While our usage of CPSCall is correct by construction to not require LLVM's stack-allocation, LLVM's code generator has free-reign to generate stack spills across a CPSCall for values that one can trivially rematerialize. I don't think it's sustainable to work around that already deeply-ingrained behavior (however silly it may be!), so instead the plan is to extend LLVM's statepoints to be compatible with GHC's runtime system. How we go about doing this depends on our desires: do we want to also use the native SP register or not? Some earlier investigation revealed that even on Windows, one could use a native SP that points to a heap-allocated object, provided ~512bytes of space is left beyond the SP for the kernel's interrupt handler. The implementation of Go does this, despite the Windows ABI forbidding it.

I didn’t know of an effort to use a different SP register. I seriously doubt that, with GHC’s use of zillions of small, heap-allocated stacks that move around during GHC, we’ll be able to leverage profiling or debugging tools in a serious way. But perhaps I need education.

Existing debugging and profiling tools (e.g., gdb and Linux perf) can become more useful for GHC if they understood how to walk the call stack, regardless of whether the frame moves in memory. One way to do this is to emit call-frame information (CFI) [1,2] in the output assembly that describes the location and layout of the frame as it changes. This would work regardless of the SP register chosen and even if the return address is kept in register. An alternative to using CFI is to use a the canonical SP register and layout, since the default "CFI" assumed by these tools is the OS's ABI. CFI is the most robust solution for GHC, since some functions allocate more than one frame per invocation to save on code size when applying a curried function (the Making a Fast Curry paper). This is of course orthogonal to the proc-point splitting concern. I believe Ben originally brought up this desire to use a native SP even for the native backend, because the work of switching to gives us both automatic CFI support and some branch-predictor performance benefits on x86-64. That's likely to be a big overhaul though, so I'm personally in favor of extending LLVM's statepoints to be compatible with GHC and concurrently but separately adding CFI support for the native backend. [1] https://sourceware.org/binutils/docs/as/CFI-directives.html[2] https://www.imperialviolet.org/2017/01/18/cfi.html

Simon

From: ghc-devs On Behalf Of Kavon Farvardin

Sent: 04 December 2019 19:32

To: Ben Gamari

Cc: GHC developers

Subject: Re: new llvm IR callbr instruction useful for proc-point splitting?

Hi Ben,

The Wiki now has a link to the Google Doc that Michal and I were working on to compile all of the notes into one place.

The key progress made on this front has been in evaluating the trade-offs of the design space being considered by GHC, but tested within Manticore.

I'm drafting a message today for the LLVM mailing list regarding one of our first options: defining a GHC ABI to redefine which stack-pointer register is used.

Once we have additional answers to the question "how much effort is it to add a GHC ABI to LLVM?", we can then then start a discussion on whether GHC wants to change instead by moving to a native stack-pointer register (to take advantage of existing debugging and profiling tools, etc).

Ideally, we would then make a decision on which option to take and someone (perhaps a GSoC student with mentorship from myself and others) with spare time can work on it.

Cheers,

Kavon

On Wed, 2019-12-04 at 11:38 -0500, Ben Gamari wrote:

...

Kavon Farvardin writes:

Yes, callbr is part of the discussion on removing proc-point splitting! Soon there will be an announcement about a new working group dedicated to LLVM issues such as this one on this mailing list. Anyone interested is welcome to join our meetings. We're currently gathering our notes together first, but you can have a look here for a preview:

https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/LLVM-Backend-Op...

...

Hi Kavon,

What ever happened to this? It came up during the GHC call and we realized that none of us knew what the state of the proposal was. Is this Wiki page still reflective of the current state of play?

Cheers,

- Ben