[llvm-dev] Fwd: Re: OCaml GC in LLVM

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Sun Sep 27 09:11:12 PDT 2015


Forwarding a message from an old email chain to the list to make sure it 
gets archived.

-------- Forwarded Message --------
Subject: 	Re: OCaml GC in LLVM
Date: 	Mon, 08 Dec 2014 14:45:39 +0300
From: 	Peter Zotov
To: 	listmail at philipreames.com



On 2014-12-08 14:35, Peter Zotov wrote:
> Hi Philip,
>
> I'm watching with great interest the progress of GC support
> in LLVM. I have some intermediate work on an OCaml backend for
> LLVM, and good GC intrinsics are what blocked me there.
>
> The in-tree OCaml GC implementation was never used by anything.
> It does generate frame tables compatible with ocamlopt, however
> it was added as a mere example--there is simply no existing
> code or infrastructure that could take advantage of it.
> It's also blitheringly inefficient, so remove at will.
>
> I think the Erlang GC is used by HiPE.

Following up with the answers to your questions:

> Questions:
> - Is proving the ability to generate a custom binary stack map format a
> valuable feature?  Adapting the new statepoint infrastructure to work
> with the existing GCMetadataPrinter classes wouldn't be particularly
> hard.

Certainly. I would use that in an OCaml LLVM backend.
This will allow me to reuse unmodifed OCaml runtime, and even mix and
match LLVM-built and ocamlopt-built code.

> - Are there any GCs out there that need gcroot's single stack slot per
> value implementation?   By default, statepoints may generate a
> different
> stackmap for every safepoint in a function.

I do not need this.

> - Is using gcroot and allocas to mark pointers as garbage collected
> references valuable?  (As opposed to using address spaces on the SSA
> values themselves?)  Long term, should we retain the gcroot marker
> intrinsics at all?

Address spaces make my codegen much simpler.

-- 
Peter Zotov



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150927/e98f8590/attachment.html>


More information about the llvm-dev mailing list