From 728f03f2adf567bd3e9bb25e5d6f97ea3d709527 Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Thu, 22 Jul 2004 05:49:38 +0000 Subject: [PATCH] Update documentation for gc intrinsics change. Contributed by Tobias Nurmiranta git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@15095 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/GarbageCollection.html | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/docs/GarbageCollection.html b/docs/GarbageCollection.html index 744279bdf31..8747e93079d 100644 --- a/docs/GarbageCollection.html +++ b/docs/GarbageCollection.html @@ -234,8 +234,8 @@ zeroed-out block of memory of the appropriate size.

- sbyte *%llvm.gcread(sbyte **)
- void %llvm.gcwrite(sbyte*, sbyte**) + sbyte *%llvm.gcread(sbyte *, sbyte **)
+ void %llvm.gcwrite(sbyte*, sbyte*, sbyte**)

Several of the more interesting garbage collectors (e.g., generational @@ -250,7 +250,9 @@ tolerable.

To support garbage collectors that use read or write barriers, LLVM provides the llvm.gcread and llvm.gcwrite intrinsics. The first 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 (llvm_gc_read and llvm_gc_write respectively), which are then @@ -341,8 +343,8 @@ implementations available.

- void *llvm_gc_read(void **)
- void llvm_gc_write(void*, void**) + void *llvm_gc_read(void*, void **)
+ void llvm_gc_write(void*, void *, void**)

@@ -353,8 +355,7 @@ pointer, then return.

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 -as a parameter in the future, if needed. +implement it.