mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-23 03:02:36 +01:00
docs: Update HTML markup(s).
llvm-svn: 137433
This commit is contained in:
parent
1b975dd6ca
commit
ecab34205a
@ -290,10 +290,8 @@ doing so is very simple. (This code is heavily commented to help you
|
||||
understand the data structure, but there are only 20 lines of meaningful
|
||||
code.)</p>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="doc_code"><pre
|
||||
>/// @brief The map for a single function's stack frame. One of these is
|
||||
<pre class="doc_code">
|
||||
/// @brief The map for a single function's stack frame. One of these is
|
||||
/// compiled as constant data into the executable for each function.
|
||||
///
|
||||
/// Storage of metadata values is elided if the %metadata parameter to
|
||||
@ -338,7 +336,9 @@ void visitGCRoots(void (*Visitor)(void **Root, const void *Meta)) {
|
||||
for (unsigned e = R->Map->NumRoots; i != e; ++i)
|
||||
Visitor(&R->Roots[i], NULL);
|
||||
}
|
||||
}</pre></div>
|
||||
}</pre>
|
||||
|
||||
</div>
|
||||
|
||||
<!-- ======================================================================= -->
|
||||
<h3>
|
||||
@ -395,12 +395,12 @@ program.</p>
|
||||
<a name="gcattr">Specifying GC code generation: <tt>gc "..."</tt></a>
|
||||
</h3>
|
||||
|
||||
<div>
|
||||
|
||||
<div class="doc_code"><tt>
|
||||
define <i>ty</i> @<i>name</i>(...) <span style="text-decoration: underline">gc "<i>name</i>"</span> { ...
|
||||
</tt></div>
|
||||
|
||||
<div>
|
||||
|
||||
<p>The <tt>gc</tt> function attribute is used to specify the desired GC style
|
||||
to the compiler. Its programmatic equivalent is the <tt>setGC</tt> method of
|
||||
<tt>Function</tt>.</p>
|
||||
@ -420,12 +420,12 @@ programs that use different garbage collection algorithms (or none at all).</p>
|
||||
<a name="gcroot">Identifying GC roots on the stack: <tt>llvm.gcroot</tt></a>
|
||||
</h3>
|
||||
|
||||
<div>
|
||||
|
||||
<div class="doc_code"><tt>
|
||||
void @llvm.gcroot(i8** %ptrloc, i8* %metadata)
|
||||
</tt></div>
|
||||
|
||||
<div>
|
||||
|
||||
<p>The <tt>llvm.gcroot</tt> intrinsic is used to inform LLVM that a stack
|
||||
variable references an object on the heap and is to be tracked for garbage
|
||||
collection. The exact impact on generated code is specified by a <a
|
||||
@ -453,7 +453,7 @@ the stack frame.</p>
|
||||
|
||||
<p>Consider the following fragment of Java code:</p>
|
||||
|
||||
<pre>
|
||||
<pre class="doc_code">
|
||||
{
|
||||
Object X; // A null-initialized reference to an object
|
||||
...
|
||||
@ -463,7 +463,7 @@ the stack frame.</p>
|
||||
<p>This block (which may be located in the middle of a function or in a loop
|
||||
nest), could be compiled to this LLVM code:</p>
|
||||
|
||||
<pre>
|
||||
<pre class="doc_code">
|
||||
Entry:
|
||||
;; In the entry block for the function, allocate the
|
||||
;; stack space for X, which is an LLVM pointer.
|
||||
@ -537,12 +537,12 @@ are used.</p>
|
||||
<a name="gcwrite">Write barrier: <tt>llvm.gcwrite</tt></a>
|
||||
</h4>
|
||||
|
||||
<div>
|
||||
|
||||
<div class="doc_code"><tt>
|
||||
void @llvm.gcwrite(i8* %value, i8* %object, i8** %derived)
|
||||
</tt></div>
|
||||
|
||||
<div>
|
||||
|
||||
<p>For write barriers, LLVM provides the <tt>llvm.gcwrite</tt> intrinsic
|
||||
function. It has exactly the same semantics as a non-volatile <tt>store</tt> to
|
||||
the derived pointer (the third argument). The exact code generated is specified
|
||||
@ -559,12 +559,12 @@ implement reference counting.</p>
|
||||
<a name="gcread">Read barrier: <tt>llvm.gcread</tt></a>
|
||||
</h4>
|
||||
|
||||
<div>
|
||||
|
||||
<div class="doc_code"><tt>
|
||||
i8* @llvm.gcread(i8* %object, i8** %derived)<br>
|
||||
</tt></div>
|
||||
|
||||
<div>
|
||||
|
||||
<p>For read barriers, LLVM provides the <tt>llvm.gcread</tt> intrinsic function.
|
||||
It has exactly the same semantics as a non-volatile <tt>load</tt> from the
|
||||
derived pointer (the second argument). The exact code generated is specified by
|
||||
|
@ -1576,11 +1576,11 @@ as if it writes to the relevant surrounding bytes.
|
||||
</div>
|
||||
|
||||
<!-- ======================================================================= -->
|
||||
<div class="doc_subsection">
|
||||
<h3>
|
||||
<a name="ordering">Atomic Memory Ordering Constraints</a>
|
||||
</div>
|
||||
</h3>
|
||||
|
||||
<div class="doc_text">
|
||||
<div>
|
||||
|
||||
<p>Atomic instructions (<a href="#i_cmpxchg"><code>cmpxchg</code></a>,
|
||||
<a href="#i_atomicrmw"><code>atomicrmw</code></a>,
|
||||
@ -4709,10 +4709,11 @@ that the invoke/unwind semantics are likely to change in future versions.</p>
|
||||
</div>
|
||||
|
||||
<!-- _______________________________________________________________________ -->
|
||||
<div class="doc_subsubsection"> <a name="i_fence">'<tt>fence</tt>'
|
||||
Instruction</a> </div>
|
||||
<h4>
|
||||
<a name="i_fence">'<tt>fence</tt>' Instruction</a>
|
||||
</h4>
|
||||
|
||||
<div class="doc_text">
|
||||
<div>
|
||||
|
||||
<h5>Syntax:</h5>
|
||||
<pre>
|
||||
@ -4763,10 +4764,11 @@ thread. (This is useful for interacting with signal handlers.)</p>
|
||||
</div>
|
||||
|
||||
<!-- _______________________________________________________________________ -->
|
||||
<div class="doc_subsubsection"> <a name="i_cmpxchg">'<tt>cmpxchg</tt>'
|
||||
Instruction</a> </div>
|
||||
<h4>
|
||||
<a name="i_cmpxchg">'<tt>cmpxchg</tt>' Instruction</a>
|
||||
</h4>
|
||||
|
||||
<div class="doc_text">
|
||||
<div>
|
||||
|
||||
<h5>Syntax:</h5>
|
||||
<pre>
|
||||
@ -4845,10 +4847,11 @@ done:
|
||||
</div>
|
||||
|
||||
<!-- _______________________________________________________________________ -->
|
||||
<div class="doc_subsubsection"> <a name="i_atomicrmw">'<tt>atomicrmw</tt>'
|
||||
Instruction</a> </div>
|
||||
<h4>
|
||||
<a name="i_atomicrmw">'<tt>atomicrmw</tt>' Instruction</a>
|
||||
</h4>
|
||||
|
||||
<div class="doc_text">
|
||||
<div>
|
||||
|
||||
<h5>Syntax:</h5>
|
||||
<pre>
|
||||
|
Loading…
Reference in New Issue
Block a user