<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>
<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_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
address space 257. Other x86 segments have yet to be allocated address space
numbers.</p>
-<p>Some operating systems use the FS/GS-segment to implement TLS, so care
- should be taken when reading and writing to address space 256/257 on these
- platforms.</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>