Add missing newlines at EOF (for clang++).

[oota-llvm.git] / docs / CodeGenerator.html

diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html
index b4edbd7356409fa324dcefba3ca91fd343bd088d..cc3a541e9c936b86c484d28cc1466ffef4cc93a1 100644 (file)
--- a/docs/CodeGenerator.html
+++ b/docs/CodeGenerator.html
@@ -600,7 +600,7 @@ BuildMI(MBB, X86::JNE, 1).addMBB(&MBB);
 
 <div class="doc_code">
 <pre>
-MI.addReg(Reg, MachineOperand::Def);
+MI.addReg(Reg, RegState::Define);
 </pre>
 </div>
 
@@ -1380,9 +1380,9 @@ bool RegMapping_Fer::compatible_class(MachineFunction &amp;mf,
    for <tt>RegisterClass</tt>, the last parameter of which is a list of
    registers. Just commenting some out is one simple way to avoid them being
    used. A more polite way is to explicitly exclude some registers from
-   the <i>allocation order</i>. See the definition of the <tt>GR</tt> register
-   class in <tt>lib/Target/IA64/IA64RegisterInfo.td</tt> for an example of this
-   (e.g., <tt>numReservedRegs</tt> registers are hidden.)</p>
+   the <i>allocation order</i>. See the definition of the <tt>GR8</tt> register
+   class in <tt>lib/Target/X86/X86RegisterInfo.td</tt> for an example of this.
+   </p>
 
 <p>Virtual registers are also denoted by integer numbers. Contrary to physical
    registers, different virtual registers never share the same number. The
@@ -1616,9 +1616,9 @@ bool RegMapping_Fer::compatible_class(MachineFunction &amp;mf,
 
 <div class="doc_code">
 <pre>
-$ llc -f -regalloc=simple file.bc -o sp.s;
-$ llc -f -regalloc=local file.bc -o lc.s;
-$ llc -f -regalloc=linearscan file.bc -o ln.s;
+$ llc -regalloc=simple file.bc -o sp.s;
+$ llc -regalloc=local file.bc -o lc.s;
+$ llc -regalloc=linearscan file.bc -o ln.s;
 </pre>
 </div>
 
@@ -1773,6 +1773,8 @@ define fastcc i32 @tailcaller(i32 %in1, i32 %in2) {
   <li><b>i386-pc-mingw32msvc</b> &mdash; MingW crosscompiler on Linux</li>
 
   <li><b>i686-apple-darwin*</b> &mdash; Apple Darwin on X86</li>
+
+  <li><b>x86_64-unknown-linux-gnu</b> &mdash; Linux</li>
 </ul>
 
 </div>
@@ -1810,24 +1812,27 @@ define fastcc i32 @tailcaller(i32 %in1, i32 %in2) {
 
 <div class="doc_code">
 <pre>
-Base + [1,2,4,8] * IndexReg + Disp32
+SegmentReg: Base + [1,2,4,8] * IndexReg + Disp32
 </pre>
 </div>
 
-<p>In order to represent this, LLVM tracks no less than 4 operands for each
+<p>In order to represent this, LLVM tracks no less than 5 operands for each
    memory operand of this form.  This means that the "load" form of
    '<tt>mov</tt>' has the following <tt>MachineOperand</tt>s in this order:</p>
 
 <div class="doc_code">
 <pre>
-Index:        0     |    1        2       3           4
-Meaning:   DestReg, | BaseReg,  Scale, IndexReg, Displacement
-OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg,   SignExtImm
+Index:        0     |    1        2       3           4          5
+Meaning:   DestReg, | BaseReg,  Scale, IndexReg, Displacement Segment
+OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg,   SignExtImm  PhysReg
 </pre>
 </div>
 
 <p>Stores, and all other instructions, treat the four memory operands in the
-   same way and in the same order.</p>
+   same way and in the same order.  If the segment register is unspecified
+   (regno = 0), then no segment override is generated.  "Lea" operations do not
+   have a segment register specified, so they only have 4 operands for their
+   memory reference.</p>
 
 </div>
 
@@ -1838,17 +1843,41 @@ OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg,   SignExtImm
 
 <div class="doc_text">
 
-<p>x86 has the ability to perform loads and stores to different address spaces
+<p>x86 has an experimental feature which provides
+   the ability to perform loads and stores to different address spaces
    via the x86 segment registers.  A segment override prefix byte on an
    instruction causes the instruction's memory access to go to the specified
    segment.  LLVM address space 0 is the default address space, which includes
    the stack, and any unqualified memory accesses in a program.  Address spaces
    1-255 are currently reserved for user-defined code.  The GS-segment is
-   represented by address space 256.  Other x86 segments have yet to be
-   allocated address space numbers.</p>
-
-<p>Some operating systems use the GS-segment to implement TLS, so care should be
-   taken when reading and writing to address space 256 on these platforms.</p>
+   represented by address space 256, while the FS-segment is represented by 
+   address space 257. Other x86 segments have yet to be allocated address space
+   numbers.</p>
+
+<p>While these address spaces may seem similar to TLS via the
+   <tt>thread_local</tt> keyword, and often use the same underlying hardware,
+   there are some fundamental differences.</p>
+
+<p>The <tt>thread_local</tt> keyword applies to global variables and
+   specifies that they are to be allocated in thread-local memory. There are
+   no type qualifiers involved, and these variables can be pointed to with
+   normal pointers and accessed with normal loads and stores.
+   The <tt>thread_local</tt> keyword is target-independent at the LLVM IR
+   level (though LLVM doesn't yet have implementations of it for some
+   configurations).<p>
+
+<p>Special address spaces, in contrast, apply to static types. Every
+   load and store has a particular address space in its address operand type,
+   and this is what determines which address space is accessed.
+   LLVM ignores these special address space qualifiers on global variables,
+   and does not provide a way to directly allocate storage in them.
+   At the LLVM IR level, the behavior of these special address spaces depends
+   in part on the underlying OS or runtime environment, and they are specific
+   to x86 (and LLVM doesn't yet handle them correctly in some cases).</p>
+
+<p>Some operating systems and runtime environments use (or may in the future
+   use) the FS/GS-segment registers for various low-level purposes, so care
+   should be taken when considering them.</p>
 
 </div>