presentation: Next-gen Haskell Compilation Techniques

Csaba Hruska csaba.hruska at
Mon Jan 11 12:18:37 UTC 2021

Hi Sebastian,

Thanks for your feedback.
I know that CIB and Perceus have issues with cycles, but these systems are
still in development so who knows what will be the conclusion.
I may not emphasize in the talk, but the goal of the grin compiler project
is to build a compiler pipeline that allows easy experimentation of
different compilation techniques. Anything between whole program
compilation to per module incremental codegen. So the whole program
compilation is not really a requirement but an option.


On Sun, Jan 10, 2021 at 1:58 PM Sebastian Graf <sgraf1337 at> wrote:

> Hi Csaba,
> Thanks for your presentation, that's a nice high-level overview of what
> you're up to.
> A few thoughts:
>    - Whole-program optimization sounds great, but also very ambitious,
>    given the amount of code GHC generates today. I'd be amazed to see advances
>    in that area, though, and your >100-module CFA performance incites hope!
>    - I wonder if going through GRIN results in a more efficient mapping
>    to hardware. I recently found that the code GHC generates is dominated by
>    administrative traffic from and to the heap [1]. I suspect that you can
>    have big wins here if you manage to convey better call stack, heap and
>    alias information to LLVM.
>    - The Control Analysis+specialisation approach sounds pretty similar
>    to doing Constructor Specialisation [2] for Lambdas (cf. 6.2) if you also
>    inline the function for which you specialise afterwards. I sunk many hours
>    into making that work reliably, fast and without code bloat in the past, to
>    no avail. Frankly, if you can do it in GRIN, I don't see why we couldn't do
>    it in Core. But maybe we can learn from the GRIN implementation afterwards
>    and maybe rethink SpecConstr. Maybe the key is not to inline the function
>    for which we specialise? But then you don't gain that much...
>    - I follow the Counting Immutable Beans [3] stuff quite closely
>    (Sebastian is a colleague of mine) and hope that it is applicable to
>    Haskell some day. But I think using Perceus, like any purely RC-based
>    memory management scheme, means that you can't have cycles in your heap, so
>    no loopy thunks (such as constant-space `ones = 1:ones`) and mutability. I
>    think that makes a pretty huge difference for many use cases. Sebastian
>    also told me that they have to adapt their solutions to the cycle
>    restriction from time to time, so far always successfully. But it comes at
>    a cost: You have to adapt the code you want to write into a form that works.
> I only read the slides, apologies if some of my points were invalidated by
> something you said.
> Keep up the good work!
> Cheers,
> Sebastian
> [1]
> [2]
> [3]
> Am So., 10. Jan. 2021 um 00:31 Uhr schrieb Csaba Hruska <
> csaba.hruska at>:
>> Hello,
>> I did an online presentation about Haskell related (futuristic)
>> compilation techniques.
>> The application of these methods is also the main motivation of my work
>> with the grin compiler project and ghc-wpc.
>> video:
>> slides:
>> Regards,
>> Csaba
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list