From f5af6ada3b0570db1afc19029cad8fb8320676ef Mon Sep 17 00:00:00 2001 From: NAKAMURA Takumi Date: Sat, 23 Apr 2011 00:30:22 +0000 Subject: docs: Introduce cascading style
and

continued on .

Section Example

Section preamble.

Subsection Example

Subsection body

FIXME: Care H5 better. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130040 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/GarbageCollection.html | 59 ++++++++++++++++++++++----------------------- 1 file changed, 29 insertions(+), 30 deletions(-) (limited to 'docs/GarbageCollection.html') diff --git a/docs/GarbageCollection.html b/docs/GarbageCollection.html index aa83a2d6d8..761e1d08ca 100644 --- a/docs/GarbageCollection.html +++ b/docs/GarbageCollection.html @@ -84,7 +84,7 @@ -
+

Garbage collection is a widely used technique that frees the programmer from having to know the lifetimes of heap objects, making software easier to produce @@ -124,14 +124,12 @@ techniques dominates any low-level losses.

This document describes the mechanisms and interfaces provided by LLVM to support accurate garbage collection.

-
-

Goals and non-goals

-
+

LLVM's intermediate representation provides garbage collection intrinsics that offer support for a broad class of @@ -198,13 +196,15 @@ compiler matures.

+
+

Getting started

-
+

Using a GC with LLVM implies many things, for example:

@@ -246,14 +246,12 @@ compiler matures.

includes a highly portable, built-in ShadowStack code generator. It is compiled into llc and works even with the interpreter and C backends.

-
-

In your compiler

-
+

To turn the shadow stack on for your functions, first call:

@@ -280,7 +278,7 @@ switching to a more advanced GC.

In your runtime -
+

The shadow stack doesn't imply a memory allocation algorithm. A semispace collector or building atop malloc are great places to start, and can @@ -347,7 +345,7 @@ void visitGCRoots(void (*Visitor)(void **Root, const void *Meta)) { About the shadow stack -

+

Unlike many GC algorithms which rely on a cooperative code generator to compile stack maps, this algorithm carefully maintains a linked list of stack @@ -372,13 +370,15 @@ in order to improve performance.

+
+

IR features

-
+

This section describes the garbage collection facilities provided by the LLVM intermediate representation. The exact behavior @@ -390,8 +390,6 @@ intended to be a complete interface to any garbage collector. A program will need to interface with the GC library using the facilities provided by that program.

-
-

Specifying GC code generation: gc "..." @@ -401,7 +399,7 @@ program.

define ty @name(...) gc "name" { ...

-
+

The gc function attribute is used to specify the desired GC style to the compiler. Its programmatic equivalent is the setGC method of @@ -426,7 +424,7 @@ programs that use different garbage collection algorithms (or none at all).

void @llvm.gcroot(i8** %ptrloc, i8* %metadata)
-
+

The llvm.gcroot intrinsic is used to inform LLVM that a stack variable references an object on the heap and is to be tracked for garbage @@ -498,7 +496,7 @@ CodeBlock: Reading and writing references in the heap -

+

Some collectors need to be informed when the mutator (the program that needs garbage collection) either reads a pointer from or writes a pointer to a field @@ -534,8 +532,6 @@ require the corresponding barrier. Such a GC plugin will replace the intrinsic calls with the corresponding load or store instruction if they are used.

-
-

Write barrier: llvm.gcwrite @@ -545,7 +541,7 @@ are used.

void @llvm.gcwrite(i8* %value, i8* %object, i8** %derived)

-
+

For write barriers, LLVM provides the llvm.gcwrite intrinsic function. It has exactly the same semantics as a non-volatile store to @@ -567,7 +563,7 @@ implement reference counting.

i8* @llvm.gcread(i8* %object, i8** %derived)
-
+

For read barriers, LLVM provides the llvm.gcread intrinsic function. It has exactly the same semantics as a non-volatile load from the @@ -580,13 +576,17 @@ writes.

+
+ +
+

Implementing a collector plugin

-
+

User code specifies which GC code generation to use with the gc function attribute or, equivalently, with the setGC method of @@ -666,14 +666,12 @@ $ llvm-as < sample.ll | llc -load=MyGC.so

It is also possible to statically link the collector plugin into tools, such as a language-specific compiler front-end.

-
-

Overview of available features

-
+

GCStrategy provides a range of features through which a plugin may do useful work. Some of these are callbacks, some are algorithms that can @@ -962,7 +960,7 @@ interest.

Computing stack maps -
+

LLVM automatically computes a stack map. One of the most important features of a GCStrategy is to compile this information into the executable in @@ -1018,7 +1016,7 @@ for collector plugins which implement reference counting or a shadow stack.

Initializing roots to null: InitRoots -
+
MyGC::MyGC() {
@@ -1044,7 +1042,7 @@ this feature should be used by all GC plugins. It is enabled by default.

     CustomReadBarriers, and CustomWriteBarriers
 
 
-

+

 
 
For GCs which use barriers or unusual treatment of stack roots, these
 flags allow the collector to perform arbitrary transformations of the LLVM
@@ -1133,7 +1131,7 @@ bool MyGC::performCustomLowering(Function &F) {
   Generating safe points: NeededSafePoints
 
 
-

+

 
 
LLVM can compute four kinds of safe points:

 
@@ -1197,7 +1195,7 @@ safe point (because only the topmost function has been patched).

   Emitting assembly code: GCMetadataPrinter
 
 
-

+

 
 
LLVM allows a plugin to print arbitrary assembly code before and after the
 rest of a module's assembly code. At the end of the module, the GC can compile
@@ -1341,6 +1339,7 @@ void MyGCPrinter::finishAssembly(std::ostream &OS, AsmPrinter &AP,
 
 

 
+

 
 
 

@@ -1348,7 +1347,7 @@ void MyGCPrinter::finishAssembly(std::ostream &OS, AsmPrinter &AP,
 

 
 
-

+

 
 
[Appel89] Runtime Tags Aren't Necessary. Andrew
 W. Appel. Lisp and Symbolic Computation 19(7):703-705, July 1989.

-- 
cgit v1.2.3