[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