* PIC codegen for X86/Linux has been implemented

* PIC-aware internal structures in X86 Codegen have been refactored
* Visibility (default/weak) has been added
* Docs fixes (external weak linkage, visibility, formatting)


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

2 files changed, 55 insertions, 23 deletions

diff --git a/docs/BytecodeFormat.html b/docs/BytecodeFormat.html
index cc0ae7ca5f..e65ee0cba4 100644
--- a/docs/BytecodeFormat.html
+++ b/docs/BytecodeFormat.html
@@ -743,7 +743,6 @@ describes the latest version, 1.3):</p>
   <li>#3: LLVM 1.3</li>
   <li>#4: LLVM 1.3.x (not released)</li>
   <li>#5: LLVM 1.4 and newer</li>
-  </li>
 </ul>
 <p>Note that we plan to eventually expand the target description
 capabilities
@@ -1082,7 +1081,11 @@ and can includes more information:</p>
       <td class="td_left">If this bit is set, a SectionID follows this vbr.</td>
     </tr>
     <tr>
-      <td><a href="#bit">bit(10-31)</a></td>
+      <td><a href="#bit">bit(10-12)</a></td>
+      <td class="td_left">Visibility style: 0=Default, 1=Hidden.</td>
+    </tr>
+    <tr>
+      <td><a href="#bit">bit(13-31)</a></td>
       <td class="td_left">Currently unassigned.</td>
     </tr>
   </tbody>
@@ -1337,7 +1340,7 @@ field values of the structure.</li>
 </div>
 
 <!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">Undef Entries</a></div>
+<div class="doc_subsubsection">Undef Entries</div>
 
 <div class="doc_text">
 <p>When the number of operands to the constant is one, we have an 'undef' value
@@ -1345,7 +1348,7 @@ of the specified type.</p>
 </div>
 
 <!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">Inline Assembler Entries</a></div>
+<div class="doc_subsubsection">Inline Assembler Entries</div>
 
 <div class="doc_text">
 <p>Inline Assembler entries are stored in the constant pool, though they are not
@@ -1369,7 +1372,7 @@ of the specified type.</p>
     </tr>
     <tr>
       <td><a href="#uint32_vbr">uint32_vbr</a></td>
-      <td class="td_left">Flags</sup></td>
+      <td class="td_left">Flags</td>
     </tr>
   </tbody>
 </table>
@@ -1380,7 +1383,7 @@ of the specified type.</p>
 </div>
 
 <!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">Constant Expression Entries</a></div>
+<div class="doc_subsubsection">Constant Expression Entries</div>
 
 <div class="doc_text">
 
@@ -1436,8 +1439,8 @@ size<br>
     </tr>
     <tr>
       <td><a href="#uint32_vbr">uint32_vbr</a></td>
-      <td class="td_left">The linkage type of the function: 0=External, 1=Weak,
-2=Appending, 3=Internal, 4=LinkOnce, 5=DllImport, 6=DllExport<sup>1</sup></td>
+      <td class="td_left"><a href="#funclinkage_and_visibility">The linkage and
+      visibility</a> style field</td>
     </tr>
     <tr>
       <td><a href="#block">block</a></td>
@@ -1470,7 +1473,34 @@ other fields will be present as the function is defined elsewhere.</li>
 be written. Compaction tables are only written if they will actually
 save bytecode space. If not, then a regular constant pool is written.</li>
 </ol>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"><a name="funclinkage_and_visibility">Linkage and
+    visibility word</a>
+</div>
+<div class="doc_text">
+
+<table>
+  <tbody>
+    <tr>
+      <th><b>Type</b></th>
+      <th class="td_left"><b>Field Description</b></th>
+    </tr>
+    <tr>
+      <td><a href="#bit">bit(0-15)</a></td>
+      <td class="td_left">The linkage type of the function: 0=External, 1=Weak,
+2=Appending, 3=Internal, 4=LinkOnce, 5=DllImport, 6=DllExport<sup>1</sup></td>
+    </tr>
+    <tr>
+      <td><a href="#bit">bit(16-31)</a></td>
+      <td class="td_left">Visibility style: 0=Default, 1=Hidden.</td>
+    </tr>
+  </tbody>
+</table>
+
+</div>
 </div>
+
 <!-- _______________________________________________________________________ -->
 <div class="doc_subsection"><a name="compactiontable">Compaction Table</a>
 </div>
diff --git a/docs/LangRef.html b/docs/LangRef.html
index e9daca07e5..2e40842dfb 100644
--- a/docs/LangRef.html
+++ b/docs/LangRef.html
@@ -275,7 +275,7 @@ purposes:</p>
   For example, %foo, %DivisionByZero, %a.really.long.identifier.  The actual
   regular expression used is '<tt>%[a-zA-Z$._][a-zA-Z$._0-9]*</tt>'.
   Identifiers which require other characters in their names can be surrounded
-  with quotes.  In this way, anything except a <tt>"</tt> character can be used
+  with quotes.  In this way, anything except a <tt>&quot;</tt> character can be used
   in a name.</li>
 
   <li>Unnamed values are represented as an unsigned numeric value with a '%'
@@ -452,6 +452,13 @@ All Global Variables and Functions have one of the following types of linkage:
   "sections" with identical names when .o files are linked.
   </dd>
 
+  <dt><tt><b><a name="linkage_externweak">extern_weak</a></b></tt>: </dt>
+  <dd>The semantics of this linkage follow the ELF model: the symbol is weak
+    until linked, if not linked, the symbol becomes null instead of being an
+    undefined reference.
+  </dd>
+</dl>
+
   <dt><tt><b><a name="linkage_external">externally visible</a></b></tt>:</dt>
 
   <dd>If none of the above identifiers are used, the global is externally
@@ -459,17 +466,13 @@ All Global Variables and Functions have one of the following types of linkage:
   external symbol references.
   </dd>
 
-  <dt><tt><b><a name="linkage_externweak">extern_weak</a></b></tt>: </dt>
-
-  <dd>"<tt>extern_weak</tt>" TBD
-  </dd>
-
   <p>
   The next two types of linkage are targeted for Microsoft Windows platform
   only. They are designed to support importing (exporting) symbols from (to)
   DLLs.
   </p>
 
+  <dl>
   <dt><tt><b><a name="linkage_dllimport">dllimport</a></b></tt>: </dt>
 
   <dd>"<tt>dllimport</tt>" linkage causes the compiler to reference a function
@@ -489,7 +492,7 @@ All Global Variables and Functions have one of the following types of linkage:
 
 </dl>
 
-<p><a name="linkage_external">For example, since the "<tt>.LC0</tt>"
+<p><a name="linkage_external"></a>For example, since the "<tt>.LC0</tt>"
 variable is defined to be internal, if another module defined a "<tt>.LC0</tt>"
 variable and was linked with this one, one of the two would be renamed,
 preventing a collision.  Since "<tt>main</tt>" and "<tt>puts</tt>" are
@@ -497,7 +500,7 @@ external (i.e., lacking any linkage declarations), they are accessible
 outside of the current module.</p>
 <p>It is illegal for a function <i>declaration</i>
 to have any linkage type other than "externally visible", <tt>dllimport</tt>,
-or <tt>extern_weak</tt>.</a></p>
+or <tt>extern_weak</tt>.</p>
 
 </div>
 
@@ -676,13 +679,13 @@ a power of 2.</p>
 
   <p>Parameter attributes consist of an at sign (@) followed by either a single
   keyword or a comma separate list of keywords enclosed in parentheses. For
-  example:<pre>
+  example:</p><pre>
     %someFunc = i16 @zext (i8 @(sext) %someParam)
     %someFunc = i16 @zext (i8 @zext %someParam)</pre>
-  Note that the two function types above are unique because the parameter
-  has a different attribute (@sext in the first one, @zext in the second).</p>
+  <p>Note that the two function types above are unique because the parameter has
+  a different attribute (@sext in the first one, @zext in the second).</p>
 
-  <p>Currently, only the following parameter attributes are defined:
+  <p>Currently, only the following parameter attributes are defined:</p>
   <dl>
     <dt><tt>@zext</tt></dt>
     <dd>This indicates that the parameter should be zero extended just before
@@ -690,7 +693,7 @@ a power of 2.</p>
     <dt><tt>@sext</tt></dt>
     <dd>This indicates that the parameter should be sign extended just before
     a call to this function.</dd>
-  </dl></p>
+  </dl>
 
   <p>The current motivation for parameter attributes is to enable the sign and
   zero extend information necessary for the C calling convention to be passed
@@ -3053,7 +3056,7 @@ a pointer type, <tt>ty2</tt>.</p>
 <h5>Arguments:</h5>
 <p>The '<tt>inttoptr</tt>' instruction takes an <a href="i_integer">integer</a>
 value to cast, and a type to cast it to, which must be a 
-<a href="#t_pointer">pointer</a> type. </tt>
+<a href="#t_pointer">pointer</a> type.
 
 <h5>Semantics:</h5>
 <p>The '<tt>inttoptr</tt>' instruction converts <tt>value</tt> to type
@@ -3172,7 +3175,6 @@ yields a <a href="#t_primitive">i1</a> result, as follows:
   <tt>true</tt> if <tt>var1</tt> is less than <tt>var2</tt>.</li>
   <li><tt>sle</tt>: interprets the operands as signed values and yields
   <tt>true</tt> if <tt>var1</tt> is less than or equal to <tt>var2</tt>.</li>
-  </li>
 </ol>
 <p>If the operands are <a href="#t_pointer">pointer</a> typed, the pointer
 values are treated as integers and then compared.</p>