[Haskell-cafe] LFVM-STG Compilation

[Bryan Richter]

Speeding up compile times would be excellent! Do you have benchmarks?
Estimates?

ZuriHac is coming up, and I want to devote my participation time to
improving ghc's usability, one way or another. Improving compile times
would be the best usability boon I can think of. If there is promise in
this project, I'd like to learn about any way I could help out.


On Thu, 9 May 2019, 15.54 james faure, <james.faure at epitech.eu> wrote:

> Hello,
> I want to introduce the STG backend I am currently working on:
> https://github.com/jfaure/lfvm-stg
> I'd love to see how much interest there is for this, to receive any
> comments, and find out if I've missed anything !
>
> The goal is to massively speed up compilation times and generate faster
> and clearer code, and in that respect I am already quite successful. Llvm
> is very well suited for encoding a (lazy) functional language, however the
> evaluation mechanism is very different to ghc's stg, there is notably no
> continuation passing nor result registers. In LFVM, all non constant let
> bindings are given an llvm function. I believe this approach is more
> natural, the llvm more accurately reflects the source code and we get
> proper stack traces in a debugger.
>
> Status:
> The project is barely a month old, and I'm working to support everything
> ghc's code generation supports.
> The STG is heavily based on the one found in ghc and, at this time and as
> far as I can tell, supports everything except multithreading, a gc and
> lazy evaluation. The current idea I think is very promising is to use an
> inferred pi calculus to elegantly implement all 3 missing parts at once.
>
> Pi calculus [1] (process calculus) In the STG
>
>    - Multithreading occurs for arguments of functions with >1 arity
>    - Perfect garbage collection is quite probably possible [2], where
>    allocation creates a new pi name, and its uses are modeled by pi calculus
>    communication
>    - Perfect Lazy evaluation (in the sense that the wrapper and
>    associated wrapped type overhead is coerced away after the first
>    evaluation) is possible in the pi calculus and closely linked the gc model.
>    I intend to make strict evaluation the default, If you want lazy (for
>    MonadFix or infinite lists or whatever), you must request it.
>
> [1]: https://en.wikipedia.org/wiki/%CE%A0-calculus
> [2]:
> https://www.researchgate.net/publication/228514964_Resources_garbage-collection_and_the_pi-calculus
>
> James Faure (Discord: J4#0303)
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20190509/70cf4d75/attachment.html>