docs: Introduce cascading style <div> and <p> continued on <h[2-5]>.

<h2>Section Example</h2>
<div> <!-- h2+div is applied -->
<p>Section preamble.</p>

<h3>Subsection Example</h3>
<p> <!-- h3+p is applied -->
Subsection body
</p>

<!-- End of section body -->
</div>

FIXME: Care H5 better.

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

1 files changed, 18 insertions, 15 deletions

diff --git a/docs/LinkTimeOptimization.html b/docs/LinkTimeOptimization.html
index 720a5e460a..b3bc4814fd 100644
--- a/docs/LinkTimeOptimization.html
+++ b/docs/LinkTimeOptimization.html
@@ -41,7 +41,7 @@
 </h2>
 <!-- *********************************************************************** -->
 
-<div class="doc_text">
+<div>
 <p>
 LLVM features powerful intermodular optimizations which can be used at link 
 time.  Link Time Optimization (LTO) is another name for intermodular optimization 
@@ -55,7 +55,7 @@ and design between the LTO optimizer and the linker.</p>
 </h2>
 <!-- *********************************************************************** -->
 
-<div class="doc_text">
+<div>
 <p>
 The LLVM Link Time Optimizer provides complete transparency, while doing 
 intermodular optimization, in the compiler tool chain. Its main goal is to let 
@@ -69,14 +69,13 @@ the linker and LLVM optimizer helps to do optimizations that are not possible
 in other models. The linker input allows the optimizer to avoid relying on 
 conservative escape analysis.
 </p>
-</div>
 
 <!-- ======================================================================= -->
 <h3>
   <a name="example1">Example of link time optimization</a>
 </h3>
 
-<div class="doc_text">
+<div>
   <p>The following example illustrates the advantages of LTO's integrated
   approach and clean interface. This example requires a system linker which
   supports LTO through the interface described in this document.  Here,
@@ -149,7 +148,7 @@ $ llvm-gcc a.o main.o -o main # &lt;-- standard link command without any modific
   <a name="alternative_approaches">Alternative Approaches</a>
 </h3>
 
-<div class="doc_text">
+<div>
   <dl>
     <dt><b>Compiler driver invokes link time optimizer separately.</b></dt>
     <dd>In this model the link time optimizer is not able to take advantage of 
@@ -175,12 +174,14 @@ $ llvm-gcc a.o main.o -o main # &lt;-- standard link command without any modific
   </dl>
 </div>
 
+</div>
+
 <!-- *********************************************************************** -->
 <h2>
   <a name="multiphase">Multi-phase communication between libLTO and linker</a>
 </h2>
 
-<div class="doc_text">
+<div>
   <p>The linker collects information about symbol defininitions and uses in 
   various link objects which is more accurate than any information collected 
   by other tools during typical build cycles.  The linker collects this 
@@ -192,14 +193,13 @@ $ llvm-gcc a.o main.o -o main # &lt;-- standard link command without any modific
   Our goal is to take advantage of tight integration between the linker and 
   the optimizer by sharing this information during various linking phases.
 </p>
-</div>
 
 <!-- ======================================================================= -->
 <h3>
   <a name="phase1">Phase 1 : Read LLVM Bitcode Files</a>
 </h3>
 
-<div class="doc_text">
+<div>
   <p>The linker first reads all object files in natural order and collects 
   symbol information. This includes native object files as well as LLVM bitcode 
   files.  To minimize the cost to the linker in the case that all .o files
@@ -223,7 +223,7 @@ $ llvm-gcc a.o main.o -o main # &lt;-- standard link command without any modific
   <a name="phase2">Phase 2 : Symbol Resolution</a>
 </h3>
 
-<div class="doc_text">
+<div>
   <p>In this stage, the linker resolves symbols using global symbol table. 
   It may report undefined symbol errors, read archive members, replace 
   weak symbols, etc.  The linker is able to do this seamlessly even though it 
@@ -236,7 +236,7 @@ $ llvm-gcc a.o main.o -o main # &lt;-- standard link command without any modific
 <h3>
   <a name="phase3">Phase 3 : Optimize Bitcode Files</a>
 </h3>
-<div class="doc_text">
+<div>
   <p>After symbol resolution, the linker tells the LTO shared object which
   symbols are needed by native object files.  In the example above, the linker 
   reports that only <tt>foo1()</tt> is used by native object files using 
@@ -252,7 +252,7 @@ $ llvm-gcc a.o main.o -o main # &lt;-- standard link command without any modific
   <a name="phase4">Phase 4 : Symbol Resolution after optimization</a>
 </h3>
 
-<div class="doc_text">
+<div>
   <p>In this phase, the linker reads optimized a native object file and 
   updates the internal global symbol table to reflect any changes. The linker 
   also collects information about any changes in use of external symbols by 
@@ -264,12 +264,14 @@ $ llvm-gcc a.o main.o -o main # &lt;-- standard link command without any modific
   bitcode files.</p>
 </div>
 
+</div>
+
 <!-- *********************************************************************** -->
 <h2>
 <a name="lto">libLTO</a>
 </h2>
 
-<div class="doc_text">
+<div>
   <p><tt>libLTO</tt> is a shared object that is part of the LLVM tools, and 
   is intended for use by a linker. <tt>libLTO</tt> provides an abstract C 
   interface to use the LLVM interprocedural optimizer without exposing details 
@@ -278,14 +280,13 @@ $ llvm-gcc a.o main.o -o main # &lt;-- standard link command without any modific
   be possible for a completely different compilation technology to provide
   a different libLTO that works with their object files and the standard
   linker tool.</p>
-</div>
 
 <!-- ======================================================================= -->
 <h3>
   <a name="lto_module_t">lto_module_t</a>
 </h3>
 
-<div class="doc_text">
+<div>
 
 <p>A non-native object file is handled via an <tt>lto_module_t</tt>.  
 The following functions allow the linker to check if a file (on disk
@@ -329,7 +330,7 @@ lto_module_get_symbol_attribute(lto_module_t, unsigned int)
   <a name="lto_code_gen_t">lto_code_gen_t</a>
 </h3>
 
-<div class="doc_text">
+<div>
 
 <p>Once the linker has loaded each non-native object files into an
 <tt>lto_module_t</tt>, it can request libLTO to process them all and
@@ -371,6 +372,8 @@ of the native object files.</p>
 
 </div>
 
+</div>
+
 <!-- *********************************************************************** -->
 
 <hr>