[LLVMdev] GC infrastructure checked in
Carl Friedrich Bolz
cfbolz at gmx.de
Mon Jan 7 07:54:23 PST 2008
Gordon Henriksen wrote:
> On 2008-01-07, at 05:29, Jon Harrop wrote:
>
>> On Monday 07 January 2008 02:32:47 Gordon Henriksen wrote:
>>
>>> Everything described in GarbageCollection.html should now be live.
>>> Phew!
>>>
>> This is wonderful news! Are there any example programs using these
>> GCs?
>
> The division of labor is such that the user program must provide the
> stack walker (in addition to the GC), so complete GC programs are
> nontrivial. This is somewhat similar to the state of exception
> handling in LLVM. It would be an excellent project to provide
> reference implementations of these facilities.
>
> That said, the PyPy group has llvmgcroot support on a branch; you
> could ask Armin Rigo <arigo at tunes dot org> for details about
> accessing it.
>
> On his benchmarks, Armin saw an 8% speedup vs. a shadow stack. Their
> gcc backend still outperforms the LLVM backend, though—and llvm-gcc
> outperforms that further still.
The second part of this is not correct. I don't think we ever even tried
llvm-gcc on the output of our C backend. What we see on x86 machines is
that LLVM's own code generators produce slower code than using LLVM's C
backend and then running GCC on this. This however is then faster than
our own C backend using GCC. Hm, summary:
pypy-llvm-backend with llvm's codegen
< pypy-c-backend with GCC
< pypy-llvm-backend using llvm's C backend and then GCC
The above is only true when using the Boehm GC, I don't really know the
numbers when using our own GC frameworks (and thus LLVM's GC support). I
guess what we would really like to have is LLVM's codegen to be better
to get rid of the shadow stack we are currently using with our own GCs.
> So perhaps those llvm-gcc GC
> extensions could be put to good use after all! :)
Right now using LLVM's GC features is not really helpful for us, because
the benefits of having a proper stack walker disappear again due to the
worse code generator of LLVM.
Cheers,
Carl Friedrich Bolz
More information about the llvm-dev
mailing list