6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-13 20:32:21 +00:00
Code Issues Projects Releases Wiki Activity

Doc updates/edits, contributed by Terence Parr!

Browse Source 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@50205 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2008-04-24 05:59:56 +00:00
parent eb5f4092d9
commit 05d670971e
2 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
docs/GarbageCollection.html
View File

@ -151,7 +151,7 @@ support accurate garbage collection.</p>
<div class="doc_text">
<p>LLVM's intermediate representation provides <a href="#intrinsics">garbage
collection intrinsics</a> which offer support for a broad class of
collection intrinsics</a> that offer support for a broad class of
collector models. For instance, the intrinsics permit:</p>
<ul>
@ -280,8 +280,8 @@ compatible runtime.</p>
<div class="doc_text">
<p>The SemiSpace runtime implements with the <a href="runtime">suggested
runtime interface</a> and is compatible the ShadowStack backend.</p>
<p>The SemiSpace runtime implements the <a href="runtime">suggested
runtime interface</a> and is compatible with the ShadowStack backend.</p>
<p>SemiSpace is a very simple copying collector. When it starts up, it
allocates two blocks of memory for the heap. It uses a simple bump-pointer
@ -321,7 +321,7 @@ may use <tt>load</tt> and <tt>store</tt> instead of <tt>llvm.gcread</tt> and
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="core">Core support</a>
<a name="core">Core support</a><a name="intrinsics"></a>
</div>
<!-- *********************************************************************** -->
@ -351,12 +351,12 @@ specified by the runtime.</p>
<div class="doc_text">
<p>The <tt>gc</tt> function attribute is used to specify the desired collector
algorithm to the compiler. It is equivalent to specify the collector name
algorithm to the compiler. It is equivalent to specifying the collector name
programmatically using the <tt>setCollector</tt> method of
<tt>Function</tt>.</p>
<p>Specifying the collector on a per-function basis allows LLVM to link together
programs which use different garbage collection algorithms.</p>
programs that use different garbage collection algorithms.</p>
</div>
@ -372,7 +372,7 @@ programs which use different garbage collection algorithms.</p>
<div class="doc_text">
<p>The <tt>llvm.gcroot</tt> intrinsic is used to inform LLVM of a pointer
variable on the stack. The first argument <b>must</b> be an alloca instruction
variable on the stack. The first argument <b>must</b> be a value referring to an alloca instruction
or a bitcast of an alloca. The second contains a pointer to metadata that
should be associated with the pointer, and <b>must</b> be a constant or global
value address. If your target collector uses tags, use a null pointer for
@ -399,7 +399,7 @@ Entry:
;; Tell LLVM that the stack space is a stack root.
;; Java has type-tags on objects, so we pass null as metadata.
%tmp = bitcast %Object** %X to i8**
call void %llvm.gcroot(%i8** %X, i8* null)
call void %llvm.gcroot(i8** %X, i8* null)
...
;; "CodeBlock" is the block corresponding to the start
@ -439,16 +439,16 @@ object). Accordingly, these intrinsics take both pointers as separate arguments
for completeness. In this snippet, <tt>%object</tt> is the object pointer, and
<tt>%derived</tt> is the derived pointer:</p>
<blockquote><pre
> ;; An array type.
<blockquote><pre>
;; An array type.
%class.Array = type { %class.Object, i32, [0 x %class.Object*] }
...
...
;; Load the object pointer from a gcroot.
%object = load %class.Array** %object_addr
;; Compute the derived pointer.
%derived = getelementptr %obj, i32 0, i32 2, i32 %n</pre></blockquote>
%derived = getelementptr %object, i32 0, i32 2, i32 %n</pre></blockquote>
</div>
@ -594,7 +594,7 @@ The <tt>llvm_cg_walk_gcroots</tt> function is a function provided by the code
generator that iterates through all of the GC roots on the stack, calling the
specified function pointer with each record. For each GC root, the address of
the pointer and the meta-data (from the <a
href="#roots"><tt>llvm.gcroot</tt></a> intrinsic) are provided.
href="#gcroot"><tt>llvm.gcroot</tt></a> intrinsic) are provided.
</p>
</div>
@ -1329,7 +1329,7 @@ href="#gcdescriptors">where pointers are located in heap objects</a>.</p>
<a href="#explicit"><tt>llvm_gc_collect</tt></a> functions. To do this, it will
probably have to <a href="#traceroots">trace through the roots
from the stack</a> and understand the <a href="#gcdescriptors">GC descriptors
for heap objects</a>. Luckily, there are some <a href="#gcimpls">example
for heap objects</a>. Luckily, there are some <a href="#usage">example
implementations</a> available.
</p>
</div>
@ -1366,7 +1366,7 @@ book-keeping is needed at all. This is common for Lisp-like languages.</li>
<p>The LLVM garbage collectors are capable of supporting all of these styles of
language, including ones that mix various implementations. To do this, it
allows the source-language to associate meta-data with the <a
href="#roots">stack roots</a>, and the heap tracing routines can propagate the
href="#gcroot">stack roots</a>, and the heap tracing routines can propagate the
information. In addition, LLVM allows the front-end to extract GC information
in any form from a specific object pointer (this supports situations #1 and #3).
</p>

8
docs/LangRef.html
View File

@ -3020,8 +3020,8 @@ provided depend on the type of the first pointer argument. The
'<tt>getelementptr</tt>' instruction is used to index down through the type
levels of a structure or to a specific index in an array. When indexing into a
structure, only <tt>i32</tt> integer constants are allowed. When indexing
into an array or pointer, only integers of 32 or 64 bits are allowed, and will
be sign extended to 64-bit values.</p>
into an array or pointer, only integers of 32 or 64 bits are allowed; 32-bit
values will be sign extended to 64-bits if required.</p>
<p>For example, let's consider a C code fragment and how it gets
compiled to LLVM:</p>
@ -3096,7 +3096,7 @@ the LLVM code for the given testcase is equivalent to:</p>
<p>Note that it is undefined to access an array out of bounds: array and
pointer indexes must always be within the defined bounds of the array type.
The one exception for this rules is zero length arrays. These arrays are
The one exception for this rule is zero length arrays. These arrays are
defined to be accessible as variable length arrays, which requires access
beyond the zero'th element.</p>
@ -4207,7 +4207,7 @@ value address) contains the meta-data to be associated with the root.</p>
<h5>Semantics:</h5>
<p>At runtime, a call to this intrinsics stores a null pointer into the "ptrloc"
<p>At runtime, a call to this intrinsic stores a null pointer into the "ptrloc"
location. At compile-time, the code generator generates information to allow
the runtime to find the pointer at GC safe points. The '<tt>llvm.gcroot</tt>'
intrinsic may only be used in a function which <a href="#gc">specifies a GC