December 2015 - ghc-devs

Plugins: Accessing unexported bindings
by Levent Erkok 08 Dec '15

08 Dec '15

Hello, The mg_binds field of the ModGuts seem to only contain the bindings that are exported from the module being compiled. I guess GHC must be running user-plugins after it drops the bindings that are not exported, which makes perfect sense for most use cases. However, I'm working on a plugin where the end-programmer embeds "properties" in the form of functions inside his/her code, which are not necessarily exported from the module under consideration. Is there a way to access all top-level bindings in a module from a plugin, even if those bindings are not exported? Thanks, -Levent.

6 17

Questions concerning the LLVM backend - i.e. 'proc point splitting'
by David Spitzenberg 08 Dec '15

08 Dec '15

Hello everybody, I've got some questions concerning the LLVM backend - i.e. the pass 'proc point splitting' in the cmm-pipeline. I'm new to this list as well as to computer science in general - at least in some sense. Being a third semester student of computer science, I'm not quite sure, whether I'm addressing the right list with this mail. Feel free to correct me, if not. I'm doing numerical stencil calculations which heavily depend on nested loops expressed as tail-recursive functions nested one in another. When compiling a module, GHC seems capable of emitting pretty good cmm-code. At least as long as the loop bodies do not contain any call to non-inlineable functions. In most cases 'loopification' fires and transforms tail-recursive calls into loops. When calling into non-inlineable functions, 'proc point splitting' is performed. This splits the loops into several mutually-recursive functions therefore significantly decreasing the possibilities of 'opt' in optimizing the code later on. This leads to pretty bad performance of the whole calculation. To avoid the presence of proc points within a loop body - and by doing so the splitting of the body - I currently try to avoid calls into non-inlineable functions by merging the nested recursive functions into one giant tail-recursive function. This works, as long as everything not defined in the module being compiled can be inlined. Apparently, this is not a long term solution. My questions: - The reason to perform 'proc point splitting' is, that LLVM IR lacks of the possibility to call into an arbitrary basic block of a function body from outside the function itself. Is this understanding right? - Are there any other possibilities to avoid 'proc point splitting' when using LLVM as a backend? - I recently read the article on an improved LLVM backend in the GHC wiki (https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend) but couldn't find any suggestions on the topic of 'proc point splitting'. Are there any plans to solve the problem either by teaching LLVM IR the lacking functionality or in any other way? I'd really like to contribute to GHC by working on this problem, but I'm not quite sure, if I'm capable of doing so. My background knowledge is still somewhat limited, but I'm working on it ;-) Thanks in advance for your help! Regards, David Spitzenberg PS.: Thanks to everyone for the great work you're doing on GHC!

3 5

Allow ambiguous types (with warning) by default
by David Feuer 08 Dec '15

08 Dec '15

The ambiguity check produces errors that are quite surprising to the uninitiated. When the check is suppressed, the errors at use sites are typically much easier to grasp. On the other hand, there's obviously a lot of value to catching mistakes as soon as possible. Would it be possible to turn that into a warning by default?

6 10

RTS linker refactoring
by Sylvain Henry 08 Dec '15

08 Dec '15

Hi devs, I have made a patch to refactor the RTS linker, especially to drastically reduce its memory usage: https://phabricator.haskell.org/D1470 We need to test it on differrent OS/architectures before it can be merged. Here is the current state: - Linux/x86-64: OK (Harbormaster and I) - Solaris/x86-64: was OK, maybe needs to be retested (@kgardas) - OpenBSD/x86-64: was OK, maybe needs to be tetested (@kgardas) - Solaris/i386: was failing with unrelated error, needs to be retested (@kgardas) - Linux/PowerPC: OK (@erikd) - Linux/ARM: was failing with unrelated #11123 (@erikd), OK? (@bgamari) - Windows: ? - MacOS: ? - ia64: ? I don't have access to Windows and Mac OS boxes so I don't even know if it compiles there. Could someone test it (validate) on these OSes and report any issue they encounter to me (by mail or on phabricator)? Do we support ia64 architecture? Thanks! Sylvain

2 2

Re: [GHC] #11177: panic! tc_hs_type: record
by Alan & Kim Zimmerman 08 Dec '15

08 Dec '15

I am travelling until Thursday, will only be able to look on Friday. Alan On 08 Dec 2015 2:44 PM, "GHC" <ghc-devs(a)haskell.org> wrote: > #11177: panic! tc_hs_type: record > ---------------------------------+----------------------------- > Reporter: apanagio | Owner: > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 7.6.3 > Resolution: | Keywords: > Operating System: Linux | Architecture: x86 > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > ---------------------------------+----------------------------- > Changes (by simonpj): > > * cc: alanz (added) > > > Comment: > > This looks like fallout from the 'refactor `ConDecl` patch. > > Alan? > > Simon > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11177#comment:1> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

A GHC Library
by Richard Eisenberg 08 Dec '15

08 Dec '15

Hi devs, It has struck me that we have a vast trove of documentation about GHC in the form of academic papers, but little organization to this trove. The papers are scattered across authors' websites, and sometimes it is hard to remember what a paper is titled when searching for it. I have thus started a wiki page here: https://ghc.haskell.org/trac/ghc/wiki/Library I would love for this page to be the Definitive List of GHC-related papers. The list I've included is, of course, woefully short, but it is a starting point. Please add to it! Have you written a GHC paper? If so, make sure it's included. Thanks, Richard

6 12

Kind equalities
by Simon Peyton Jones 07 Dec '15

07 Dec '15

Richard What’s your ETA on the kind-equality stuff? We wondered in today’s call. We want to make an RC next week. Simon

2 1

[ANNOUNCE] 7.10.3 release candidate 2
by Ben Gamari 07 Dec '15

07 Dec '15

Hello everyone, We are pleased to announce the second release candidate for GHC 7.10.3: https://downloads.haskell.org/~ghc/7.10.3-rc2/ This release differs from -rc1 by only two commits, * Disable the newly-introduced readelf configure check on non-ELF platforms. * Remove some tracing output from the typechecker that was causing some testsuites to fail. At the moment you should find the source tarball as well as 32- and 64-bit modern Linux (built on Debian 8) binary distributions available at the above URL. Windows and CentOS binaries will be made available shortly. As usual, you may need to work around our content delivery network's update latency by adding redundant forward-slashes to the URL. As far as OS X support goes, we are still looking for contributors to help us to support their platform by offering access to hardware, testing, or builds. Please let us know if you would be willing to provide any of the above. Happy testing! Cheers, - Ben

7 22

How do I use CallStack?
by Richard Eisenberg 07 Dec '15

07 Dec '15

Hi devs, I wish to use the new CallStack feature to track call sites of a function. I want my function to print out where it was called from. I do not want to call `error`. How do I do this? I looked in the release notes. They describe the CallStack feature at an overview, and the docs suggest that it has a Show instance. But the notes don't say where to import CallStack from. I found it in GHC.Stack, but I'm unsure this is the right place to take it from. The GHC release notes also refer me to the ghc-prim release notes. These (which I assume are ghc-prim/changelog.md) don't discuss CallStack. In any case, when I try to `show ?callstack`, I learn that CallStack is not an instance of Show, or I somehow haven't imported the instance. Help? Thanks! Richard

8 13

Haddock for GHC 8.0
by Ben Gamari 07 Dec '15

07 Dec '15

tl;dr: Help needed to bring Haddock up-to-date for the GHC 8.0 release. Hello everyone, As you likely know, the GHC 8.0 release cycle is quickly drawing to a close. One of the tasks that remains outstanding is porting the patches on Haddock's `ghc-head` branch to `master`. This task is bound to require a bit more work than usual this time around as both GHC and Haddock have evolved significantly (which is a good thing!). Sadly, Austin and I are quite busy at the moment and would be hard-pressed to undertake such a task ourselves. Consequently, we need a volunteer to pick up this work. At the moment the GHC release schedule is largely determined by progress on the no-kinds branch but we expect to have a release candidate out within the next two weeks. If we aren't able to find someone to bring haddock up-to-date by mid-January I'm afraid we'll have to release GHC 8.0 with the current state of the `ghc-head` branch. Considering the significant effort that went into this summer's GSoC projects, this would be a shame. If you think you might be able to contribute to this effort, please say so in this thread. Thanks for all of your effort, - Ben

1 0