[LLVMdev] Writing LLVM front-end

David Jones djones at xtreme-eda.com
Fri Feb 20 06:17:23 PST 2015


The path of least effort, as I previously stated, is to use Boehm-GC.

Reference-counted smart pointers will require that you implement the
reference counting in your language, in the generated code. e.g. a
statement such as:

p1 = p2

really compiles into:

p1.refcount--; if (!p1.refcount) free(p1)
p1 = p2
p1.refcount++

If you want your language to be thread-safe, then the increment and
decrement operations must be atomic.

Although this is doable, your implementation must be perfect. Any bug, and
you will either leak memory, or prematurely free a pointer. I speak from
experience. Also be aware that pure reference counting will not collect
cyclic data structures.

The "LLVM GC" web page does not document a specific, usable, garbage
collector. Rather, it documents the features that LLVM provides to
interoperate with garbage collectors that require special considerations
for loads and stores. For example, parallel and incremental garbage
collection often requires that each pointer dereference first checks if the
pointee needs to be scanned. The functionality of the "LLVM GC" support
allows this to happen. However, you must still provide your own collector.


On Fri, Feb 20, 2015 at 9:01 AM, Ahmed Taj elsir <meedo456123 at gmail.com>
wrote:

> Thank you all,
>
> David Jones
>
> >>> You would then implement your own garbage collector in your runtime.
> If you don't >>> want to do that, then consider using the
> Boehm-Demers-Weiser conservative
> >>> collector. It requires no special support from LLVM.
>
> I was thinking to implement smart pointer instead of using GC , I mean
> like this:
> >>> obj b = new obj();
> b will automatically be instantiate as smart pointer (which will be
> deleted automatic also).
> I don't know if it's bad idea or not , but that what I thought .
>
> Another solution is to implement GC using LLVM GC (described here
> http://llvm.org/docs/GarbageCollection.html) , but I don't know its
> performance .
>
> Can you advice me to the best solution , between the first and the
> second solution ? does LLVM GC better than python's GC and other
> equivalents ?
>
> Thanks.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150220/98bb3235/attachment.html>


More information about the llvm-dev mailing list