docs: Update HTML markup(s).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137433 91177308-0d34-0410-b5e6-96231b3b80d8

2 files changed, 30 insertions, 27 deletions

diff --git a/docs/GarbageCollection.html b/docs/GarbageCollection.html
index 761e1d08ca..a226b0ee3e 100644
--- a/docs/GarbageCollection.html
+++ b/docs/GarbageCollection.html
@@ -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(&amp;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
diff --git a/docs/LangRef.html b/docs/LangRef.html
index 583ef83f1c..b20f085176 100644
--- a/docs/LangRef.html
+++ b/docs/LangRef.html
@@ -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>