<div class="doc_code">
<pre>
-MI.addReg(Reg, MachineOperand::Def);
+MI.addReg(Reg, RegState::Define);
</pre>
</div>
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
<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>
(because one or more of above constraints are not met) to be followed by a
readjustment of the stack. So performance might be worse in such cases.</p>
-<p>On x86 and x86-64 one register is reserved for indirect tail calls (e.g via a
- function pointer). So there is one less register for integer argument
- passing. For x86 this means 2 registers (if <tt>inreg</tt> parameter
- attribute is used) and for x86-64 this means 5 register are used.</p>
-
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<li><b>i386-pc-mingw32msvc</b> — MingW crosscompiler on Linux</li>
<li><b>i686-apple-darwin*</b> — Apple Darwin on X86</li>
+
+ <li><b>x86_64-unknown-linux-gnu</b> — Linux</li>
</ul>
</div>
<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>
<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>