6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2025-02-11 11:34:02 +00:00
Code Issues Projects Releases Wiki Activity

Update documentation for gc intrinsics change. Contributed by

Browse Source 
Tobias Nurmiranta


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@15095 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2004-07-22 05:49:38 +00:00
parent de1618f1bb
commit 728f03f2ad
1 changed files with 8 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
docs/GarbageCollection.html
View File

@ -234,8 +234,8 @@ zeroed-out block of memory of the appropriate size.</p>
<div class="doc_text"> <div class="doc_text">
<div class="doc_code"><tt> <div class="doc_code"><tt>
sbyte *%llvm.gcread(sbyte **)<br> sbyte *%llvm.gcread(sbyte *, sbyte **)<br>
void %llvm.gcwrite(sbyte*, sbyte**) void %llvm.gcwrite(sbyte*, sbyte*, sbyte**)
</tt></div> </tt></div>
<p>Several of the more interesting garbage collectors (e.g., generational <p>Several of the more interesting garbage collectors (e.g., generational
@ -250,7 +250,9 @@ tolerable.</p>
<p>To support garbage collectors that use read or write barriers, LLVM provides <p>To support garbage collectors that use read or write barriers, LLVM provides
the <tt>llvm.gcread</tt> and <tt>llvm.gcwrite</tt> intrinsics. The first the <tt>llvm.gcread</tt> and <tt>llvm.gcwrite</tt> intrinsics. The first
intrinsic has exactly the same semantics as a non-volatile LLVM load and the intrinsic has exactly the same semantics as a non-volatile LLVM load and the
second has the same semantics as a non-volatile LLVM store. At code generation second has the same semantics as a non-volatile LLVM store, with the
additions that they also take a pointer to the start of the memory
object as an argument. At code generation
time, these intrinsics are replaced with calls into the garbage collector time, these intrinsics are replaced with calls into the garbage collector
(<tt><a href="#llvm_gc_readwrite">llvm_gc_read</a></tt> and <tt><a (<tt><a href="#llvm_gc_readwrite">llvm_gc_read</a></tt> and <tt><a
href="#llvm_gc_readwrite">llvm_gc_write</a></tt> respectively), which are then href="#llvm_gc_readwrite">llvm_gc_write</a></tt> respectively), which are then
@ -341,8 +343,8 @@ implementations</a> available.
<div class="doc_text"> <div class="doc_text">
<div class="doc_code"><tt> <div class="doc_code"><tt>
void *llvm_gc_read(void **)<br> void *llvm_gc_read(void*, void **)<br>
void llvm_gc_write(void*, void**) void llvm_gc_write(void*, void *, void**)
</tt></div> </tt></div>
<p> <p>
@ -353,8 +355,7 @@ pointer, then return.
<p> <p>
If an actual read or write barrier is needed, it should be straight-forward to If an actual read or write barrier is needed, it should be straight-forward to
implement it. Note that we may add a pointer to the start of the memory object implement it.
as a parameter in the future, if needed.
</p> </p>
</div> </div>