<p>LLVM allows an explicit section to be specified for globals. If the target
supports it, it will emit globals to the section specified.</p>
-<p>An explicit alignment may be specified for a global. If not present, or if
- the alignment is set to zero, the alignment of the global is set by the
- target to whatever it feels convenient. If an explicit alignment is
- specified, the global is forced to have at least that much alignment. All
- alignments must be a power of 2.</p>
+<p>An explicit alignment may be specified for a global, which must be a power
+ of 2. If not present, or if the alignment is set to zero, the alignment of
+ the global is set by the target to whatever it feels convenient. If an
+ explicit alignment is specified, the global is forced to have exactly that
+ alignment. Targets and optimizers are not allowed to over-align the global
+ if the global has an assigned section. In this case, the extra alignment
+ could be observable: for example, code could assume that the globals are
+ densely packed in their section and try to iterate over them as an array,
+ alignment padding would break this iteration.</p>
<p>For example, the following defines a global in a numbered address space with
an initializer, section, and alignment:</p>
</dl>
<p>When constructing the data layout for a given target, LLVM starts with a
- default set of specifications which are then (possibly) overriden by the
+ default set of specifications which are then (possibly) overridden by the
specifications in the <tt>datalayout</tt> keyword. The default specifications
are given in this list:</p>
effects has nevertheless detected a condition which results in undefined
behavior.</p>
-<p>Any value other than a non-intrinsic call, invoke, or phi with a trap
- operand has trap as its result value. Any instruction with
- a trap operand which may have side effects emits those side effects as
- if it had an undef operand instead. If the side effects are externally
- visible, the behavior is undefined.</p>
+<p>There is currently no way of representing a trap value in the IR; they
+ only exist when produced by operations such as
+ <a href="#i_add"><tt>add</tt></a> with the <tt>nsw</tt> flag.</p>
-<p>Trap values may be stored to memory; a load from memory including any
- part of a trap value results in a (full) trap value.</p>
-
-<p>For example:</p>
+<p>Trap value behavior is defined in terms of value <i>dependence</i>:</p>
-<!-- FIXME: In the case of multiple threads, this only applies to loads from
- the same thread as the store, or loads which are sequenced after the
- store by synchronization. -->
+<p>
+<ul>
+<li>Values other than <a href="#i_phi"><tt>phi</tt></a> nodes depend on
+ their operands.</li>
-<div class="doc_code">
-<pre>
-%trap = sub nuw i32 0, 1 ; Results in a trap value.
-%still_trap = and i32 %trap, 0 ; Whereas (and i32 undef, 0) would return 0.
-%trap_yet_again = getelementptr i32* @h, i32 %still_trap
-store i32 0, i32* %trap_yet_again ; undefined behavior
+<li><a href="#i_phi"><tt>Phi</tt></a> nodes depend on the operand corresponding
+ to their dynamic predecessor basic block.</li>
-volatile store i32 %trap, i32* @g ; External observation; undefined behavior.
-%trap2 = load i32* @g ; Returns a trap value, not just undef.
-%narrowaddr = bitcast i32* @g to i16*
-%wideaddr = bitcast i32* @g to i64*
-%trap3 = load 16* %narrowaddr ; Returns a trap value
-%trap4 = load i64* %widaddr ; Returns a trap value, not partial trap.
-</pre>
-</div>
+<li>Function arguments depend on the corresponding actual argument values in
+ the dynamic callers of their functions.</li>
+
+<li><a href="#i_call"><tt>Call</tt></a> instructions depend on the
+ <a href="#i_ret"><tt>ret</tt></a> instructions that dynamically transfer
+ control back to them.</li>
+
+<li><a href="#i_invoke"><tt>Invoke</tt></a> instructions depend on the
+ <a href="#i_ret"><tt>ret</tt></a>, <a href="#i_unwind"><tt>unwind</tt></a>,
+ or exception-throwing call instructions that dynamically transfer control
+ back to them.</li>
+
+<li>Non-volatile loads and stores depend on the most recent stores to all of the
+ referenced memory addresses, following the order in the IR
+ (including loads and stores implied by intrinsics such as
+ <a href="#int_memcpy"><tt>@llvm.memcpy</tt></a>.)</li>
+
+<!-- TODO: In the case of multiple threads, this only applies if the store
+ "happens-before" the load or store. -->
+
+<!-- TODO: floating-point exception state -->
+
+<li>An instruction with externally visible side effects depends on the most
+ recent preceding instruction with externally visible side effects, following
+ the order in the IR. (This includes volatile loads and stores.)</li>
+
+<li>An instruction <i>control-depends</i> on a
+ <a href="#terminators">terminator instruction</a>
+ if the terminator instruction has multiple successors and the instruction
+ is always executed when control transfers to one of the successors, and
+ may not be executed when control is transfered to another.</li>
+
+<li>Dependence is transitive.</li>
-<p>If a <a href="#i_br"><tt>br</tt></a> or
- <a href="#i_switch"><tt>switch</tt></a> instruction has a trap value
- operand, all non-phi non-void instructions which control-depend on it
- have trap as their result value. A <a href="#i_phi"><tt>phi</tt></a>
- node with an incoming value associated with a control edge which is
- control-dependent on it has trap as its result value when control is
- transferred from that block. If any instruction which control-depends
- on the <tt>br</tt> or <tt>switch</tt> invokes externally visible side
- effects, the behavior of the program is undefined. For example:</p>
+</ul>
+</p>
-<!-- FIXME: What about exceptions thrown from control-dependent instrs? -->
+<p>Whenever a trap value is generated, all values which depend on it evaluate
+ to trap. If they have side effects, the evoke their side effects as if each
+ operand with a trap value were undef. If they have externally-visible side
+ effects, the behavior is undefined.</p>
+
+<p>Here are some examples:</p>
<div class="doc_code">
<pre>
entry:
%trap = sub nuw i32 0, 1 ; Results in a trap value.
- %cmp = icmp i32 slt %trap, 0 ; Still trap.
+ %still_trap = and i32 %trap, 0 ; Whereas (and i32 undef, 0) would return 0.
+ %trap_yet_again = getelementptr i32* @h, i32 %still_trap
+ store i32 0, i32* %trap_yet_again ; undefined behavior
+
+ store i32 %trap, i32* @g ; Trap value conceptually stored to memory.
+ %trap2 = load i32* @g ; Returns a trap value, not just undef.
+
+ volatile store i32 %trap, i32* @g ; External observation; undefined behavior.
+
+ %narrowaddr = bitcast i32* @g to i16*
+ %wideaddr = bitcast i32* @g to i64*
+ %trap3 = load 16* %narrowaddr ; Returns a trap value.
+ %trap4 = load i64* %widaddr ; Returns a trap value.
+
+ %cmp = icmp i32 slt %trap, 0 ; Returns a trap value.
%br i1 %cmp, %true, %end ; Branch to either destination.
true:
- volatile store i32 0, i32* @g ; Externally visible side effects
- ; control-dependent on %cmp.
- ; Undefined behavior.
+ volatile store i32 0, i32* @g ; This is control-dependent on %cmp, so
+ ; it has undefined behavior.
br label %end
end:
%p = phi i32 [ 0, %entry ], [ 1, %true ]
; Both edges into this PHI are
; control-dependent on %cmp, so this
- ; results in a trap value.
+ ; always results in a trap value.
volatile store i32 0, i32* @g ; %end is control-equivalent to %entry
; so this is defined (ignoring earlier
; undefined behavior in this example).
-
</pre>
</div>
-<p>There is currently no way of representing a trap constant in the IR; they
- only exist when produced by certain instructions, such as an
- <a href="#i_add"><tt>add</tt></a> with the <tt>nsw</tt> flag
- set, when overflow occurs.</p>
-
</div>
<!-- ======================================================================= -->
attached to it that contains a constant integer. If present, the code
generator will use the integer as the location cookie value when report
errors through the LLVMContext error reporting mechanisms. This allows a
- front-end to corrolate backend errors that occur with inline asm back to the
+ front-end to correlate backend errors that occur with inline asm back to the
source code that produced it. For example:</p>
<div class="doc_code">
</div>
<div class="doc_text">
-
-<p>TODO: Describe this.</p>
+<pre>
+%0 = type { i32, void ()* }
+@llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }]
+</pre>
+<p>The <tt>@llvm.global_ctors</tt> array contains a list of constructor functions and associated priorities. The functions referenced by this array will be called in ascending order of priority (i.e. lowest first) when the module is loaded. The order of functions with the same priority is not defined.
+</p>
</div>
</div>
<div class="doc_text">
+<pre>
+%0 = type { i32, void ()* }
+@llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }]
+</pre>
-<p>TODO: Describe this.</p>
+<p>The <tt>@llvm.global_dtors</tt> array contains a list of destructor functions and associated priorities. The functions referenced by this array will be called in descending order of priority (i.e. highest first) when the module is loaded. The order of functions with the same priority is not defined.
+</p>
</div>
any integer bit width. Not all targets support all bit widths however.</p>
<pre>
- declare i8 @llvm.atomic.load.add.i8..p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.add.i16..p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.add.i32..p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.add.i64..p0i64( i64* <ptr>, i64 <delta> )
+ declare i8 @llvm.atomic.load.add.i8.p0i8( i8* <ptr>, i8 <delta> )
+ declare i16 @llvm.atomic.load.add.i16.p0i16( i16* <ptr>, i16 <delta> )
+ declare i32 @llvm.atomic.load.add.i32.p0i32( i32* <ptr>, i32 <delta> )
+ declare i64 @llvm.atomic.load.add.i64.p0i64( i64* <ptr>, i64 <delta> )
</pre>
<h5>Overview:</h5>
<pre>
declare i8 @llvm.atomic.load.min.i8.p0i8( i8* <ptr>, i8 <delta> )
declare i16 @llvm.atomic.load.min.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.min.i32..p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.min.i64..p0i64( i64* <ptr>, i64 <delta> )
+ declare i32 @llvm.atomic.load.min.i32.p0i32( i32* <ptr>, i32 <delta> )
+ declare i64 @llvm.atomic.load.min.i64.p0i64( i64* <ptr>, i64 <delta> )
</pre>
<pre>
</pre>
<pre>
- declare i8 @llvm.atomic.load.umin.i8..p0i8( i8* <ptr>, i8 <delta> )
+ declare i8 @llvm.atomic.load.umin.i8.p0i8( i8* <ptr>, i8 <delta> )
declare i16 @llvm.atomic.load.umin.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.umin.i32..p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.umin.i64..p0i64( i64* <ptr>, i64 <delta> )
+ declare i32 @llvm.atomic.load.umin.i32.p0i32( i32* <ptr>, i32 <delta> )
+ declare i64 @llvm.atomic.load.umin.i64.p0i64( i64* <ptr>, i64 <delta> )
</pre>
<h5>Overview:</h5>
projects / oota-llvm.git / blobdiff