1 {{+bindTo:partials.standard_nacl_article}}
3 <section id=
"contents-of-pnacl-bitcode-files">
4 <h1 id=
"contents-of-pnacl-bitcode-files">Contents Of PNaCl Bitcode Files
</h1>
5 <div class=
"contents local" id=
"contents" style=
"display: none">
7 <li><a class=
"reference internal" href=
"#introduction" id=
"id6">Introduction
</a></li>
8 <li><a class=
"reference internal" href=
"#data-model" id=
"id7">Data Model
</a></li>
9 <li><a class=
"reference internal" href=
"#pnacl-blocks" id=
"id8">PNaCl Blocks
</a></li>
10 <li><a class=
"reference internal" href=
"#pnacl-records" id=
"id9">PNaCl Records
</a></li>
11 <li><a class=
"reference internal" href=
"#default-abbreviations" id=
"id10">Default Abbreviations
</a></li>
12 <li><a class=
"reference internal" href=
"#pnacl-identifiers" id=
"id11">PNaCl Identifiers
</a></li>
13 <li><a class=
"reference internal" href=
"#conventions-for-describing-records" id=
"id12">Conventions For Describing Records
</a></li>
14 <li><a class=
"reference internal" href=
"#factorial-example" id=
"id13">Factorial Example
</a></li>
15 <li><a class=
"reference internal" href=
"#road-map" id=
"id14">Road Map
</a></li>
16 <li><p class=
"first"><a class=
"reference internal" href=
"#global-state" id=
"id15">Global State
</a></p>
17 <ul class=
"small-gap">
18 <li><a class=
"reference internal" href=
"#typing-functions" id=
"id16">Typing Functions
</a></li>
19 <li><a class=
"reference internal" href=
"#link-to-id-counters" id=
"id17">ID Counters
</a></li>
20 <li><a class=
"reference internal" href=
"#size-variables" id=
"id18">Size Variables
</a></li>
21 <li><a class=
"reference internal" href=
"#other-variables" id=
"id19">Other Variables
</a></li>
24 <li><p class=
"first"><a class=
"reference internal" href=
"#global-records" id=
"id20">Global Records
</a></p>
25 <ul class=
"small-gap">
26 <li><a class=
"reference internal" href=
"#header-record" id=
"id21">Header Record
</a></li>
27 <li><a class=
"reference internal" href=
"#enter-block-record" id=
"id22">Enter Block Record
</a></li>
28 <li><a class=
"reference internal" href=
"#exit-block-record" id=
"id23">Exit Block Record
</a></li>
29 <li><a class=
"reference internal" href=
"#abbreviation-record" id=
"id24">Abbreviation Record
</a></li>
32 <li><p class=
"first"><a class=
"reference internal" href=
"#types-block" id=
"id25">Types Block
</a></p>
33 <ul class=
"small-gap">
34 <li><a class=
"reference internal" href=
"#count-record" id=
"id26">Count Record
</a></li>
35 <li><a class=
"reference internal" href=
"#void-type" id=
"id27">Void Type
</a></li>
36 <li><a class=
"reference internal" href=
"#integer-types" id=
"id28">Integer Types
</a></li>
37 <li><a class=
"reference internal" href=
"#bit-floating-point-type" id=
"id29">32-Bit Floating Point Type
</a></li>
38 <li><a class=
"reference internal" href=
"#id1" id=
"id30">64-bit Floating Point Type
</a></li>
39 <li><a class=
"reference internal" href=
"#vector-types" id=
"id31">Vector Types
</a></li>
40 <li><a class=
"reference internal" href=
"#function-type" id=
"id32">Function Type
</a></li>
43 <li><p class=
"first"><a class=
"reference internal" href=
"#globals-block" id=
"id33">Globals Block
</a></p>
44 <ul class=
"small-gap">
45 <li><a class=
"reference internal" href=
"#link-for-globals-count-record" id=
"id34">Count Record
</a></li>
46 <li><a class=
"reference internal" href=
"#global-variable-addresses" id=
"id35">Global Variable Addresses
</a></li>
47 <li><a class=
"reference internal" href=
"#global-constant-addresses" id=
"id36">Global Constant Addresses
</a></li>
48 <li><a class=
"reference internal" href=
"#zerofill-initializer" id=
"id37">Zerofill Initializer
</a></li>
49 <li><a class=
"reference internal" href=
"#data-initializer" id=
"id38">Data Initializer
</a></li>
50 <li><a class=
"reference internal" href=
"#relocation-initializer" id=
"id39">Relocation Initializer
</a></li>
51 <li><a class=
"reference internal" href=
"#subfield-relocation-initializer" id=
"id40">Subfield Relocation Initializer
</a></li>
52 <li><a class=
"reference internal" href=
"#compound-initializer" id=
"id41">Compound Initializer
</a></li>
55 <li><p class=
"first"><a class=
"reference internal" href=
"#valuesymtab-block" id=
"id42">Valuesymtab Block
</a></p>
56 <ul class=
"small-gap">
57 <li><a class=
"reference internal" href=
"#entry-record" id=
"id43">Entry Record
</a></li>
60 <li><p class=
"first"><a class=
"reference internal" href=
"#module-block" id=
"id44">Module Block
</a></p>
61 <ul class=
"small-gap">
62 <li><a class=
"reference internal" href=
"#version-record" id=
"id45">Version Record
</a></li>
63 <li><a class=
"reference internal" href=
"#function-address" id=
"id46">Function Address
</a></li>
66 <li><p class=
"first"><a class=
"reference internal" href=
"#constants-blocks" id=
"id47">Constants Blocks
</a></p>
67 <ul class=
"small-gap">
68 <li><a class=
"reference internal" href=
"#set-type-record" id=
"id48">Set Type Record
</a></li>
69 <li><a class=
"reference internal" href=
"#undefined-literal" id=
"id49">Undefined Literal
</a></li>
70 <li><a class=
"reference internal" href=
"#integer-literal" id=
"id50">Integer Literal
</a></li>
71 <li><a class=
"reference internal" href=
"#floating-point-literal" id=
"id51">Floating Point Literal
</a></li>
74 <li><p class=
"first"><a class=
"reference internal" href=
"#function-blocks" id=
"id52">Function Blocks
</a></p>
75 <ul class=
"small-gap">
76 <li><a class=
"reference internal" href=
"#function-enter" id=
"id53">Function Enter
</a></li>
77 <li><a class=
"reference internal" href=
"#link-for-basic-blocks-count" id=
"id54">Count Record
</a></li>
80 <li><p class=
"first"><a class=
"reference internal" href=
"#terminator-instructions" id=
"id55">Terminator Instructions
</a></p>
81 <ul class=
"small-gap">
82 <li><a class=
"reference internal" href=
"#return-void-instruction" id=
"id56">Return Void Instruction
</a></li>
83 <li><a class=
"reference internal" href=
"#return-value-instruction" id=
"id57">Return Value Instruction
</a></li>
84 <li><a class=
"reference internal" href=
"#unconditional-branch-instruction" id=
"id58">Unconditional Branch Instruction
</a></li>
85 <li><a class=
"reference internal" href=
"#conditional-branch-instruction" id=
"id59">Conditional Branch Instruction
</a></li>
86 <li><a class=
"reference internal" href=
"#unreachable" id=
"id60">Unreachable
</a></li>
87 <li><a class=
"reference internal" href=
"#switch-instruction" id=
"id61">Switch Instruction
</a></li>
90 <li><p class=
"first"><a class=
"reference internal" href=
"#integer-binary-instructions" id=
"id62">Integer Binary Instructions
</a></p>
91 <ul class=
"small-gap">
92 <li><a class=
"reference internal" href=
"#integer-add" id=
"id63">Integer Add
</a></li>
93 <li><a class=
"reference internal" href=
"#integer-subtract" id=
"id64">Integer Subtract
</a></li>
94 <li><a class=
"reference internal" href=
"#integer-multiply" id=
"id65">Integer Multiply
</a></li>
95 <li><a class=
"reference internal" href=
"#signed-integer-divide" id=
"id66">Signed Integer Divide
</a></li>
96 <li><a class=
"reference internal" href=
"#unsigned-integer-divide" id=
"id67">Unsigned Integer Divide
</a></li>
97 <li><a class=
"reference internal" href=
"#signed-integer-remainder" id=
"id68">Signed Integer Remainder
</a></li>
98 <li><a class=
"reference internal" href=
"#unsigned-integer-remainder-instruction" id=
"id69">Unsigned Integer Remainder Instruction
</a></li>
99 <li><a class=
"reference internal" href=
"#shift-left" id=
"id70">Shift Left
</a></li>
100 <li><a class=
"reference internal" href=
"#logical-shift-right" id=
"id71">Logical Shift Right
</a></li>
101 <li><a class=
"reference internal" href=
"#arithmetic-shift-right" id=
"id72">Arithmetic Shift Right
</a></li>
102 <li><a class=
"reference internal" href=
"#logical-and" id=
"id73">Logical And
</a></li>
103 <li><a class=
"reference internal" href=
"#logical-or" id=
"id74">Logical Or
</a></li>
104 <li><a class=
"reference internal" href=
"#logical-xor" id=
"id75">Logical Xor
</a></li>
107 <li><p class=
"first"><a class=
"reference internal" href=
"#floating-point-binary-instructions" id=
"id76">Floating Point Binary Instructions
</a></p>
108 <ul class=
"small-gap">
109 <li><a class=
"reference internal" href=
"#floating-point-add" id=
"id77">Floating Point Add
</a></li>
110 <li><a class=
"reference internal" href=
"#floating-point-subtract" id=
"id78">Floating Point Subtract
</a></li>
111 <li><a class=
"reference internal" href=
"#floating-point-multiply" id=
"id79">Floating Point Multiply
</a></li>
112 <li><a class=
"reference internal" href=
"#floating-point-divide" id=
"id80">Floating Point Divide
</a></li>
113 <li><a class=
"reference internal" href=
"#floating-point-remainder" id=
"id81">Floating Point Remainder
</a></li>
116 <li><p class=
"first"><a class=
"reference internal" href=
"#memory-creation-and-access-instructions" id=
"id82">Memory Creation and Access Instructions
</a></p>
117 <ul class=
"small-gap">
118 <li><a class=
"reference internal" href=
"#alloca-instruction" id=
"id83">Alloca Instruction
</a></li>
119 <li><a class=
"reference internal" href=
"#load-instruction" id=
"id84">Load Instruction
</a></li>
120 <li><a class=
"reference internal" href=
"#store-instruction" id=
"id85">Store Instruction
</a></li>
123 <li><p class=
"first"><a class=
"reference internal" href=
"#conversion-instructions" id=
"id86">Conversion Instructions
</a></p>
124 <ul class=
"small-gap">
125 <li><a class=
"reference internal" href=
"#integer-truncating-instruction" id=
"id87">Integer Truncating Instruction
</a></li>
126 <li><a class=
"reference internal" href=
"#floating-point-truncating-instruction" id=
"id88">Floating Point Truncating Instruction
</a></li>
127 <li><a class=
"reference internal" href=
"#zero-extending-instruction" id=
"id89">Zero Extending Instruction
</a></li>
128 <li><a class=
"reference internal" href=
"#sign-extending-instruction" id=
"id90">Sign Extending Instruction
</a></li>
129 <li><a class=
"reference internal" href=
"#floating-point-extending-instruction" id=
"id91">Floating Point Extending Instruction
</a></li>
130 <li><a class=
"reference internal" href=
"#floating-point-to-unsigned-integer-instruction" id=
"id92">Floating Point to Unsigned Integer Instruction
</a></li>
131 <li><a class=
"reference internal" href=
"#floating-point-to-signed-integer-instruction" id=
"id93">Floating Point to Signed Integer Instruction
</a></li>
132 <li><a class=
"reference internal" href=
"#unsigned-integer-to-floating-point-instruction" id=
"id94">Unsigned Integer to Floating Point Instruction
</a></li>
133 <li><a class=
"reference internal" href=
"#signed-integer-to-floating-point-instruction" id=
"id95">Signed Integer to Floating Point Instruction
</a></li>
134 <li><a class=
"reference internal" href=
"#bitcast-instruction" id=
"id96">Bitcast Instruction
</a></li>
137 <li><p class=
"first"><a class=
"reference internal" href=
"#comparison-instructions" id=
"id97">Comparison Instructions
</a></p>
138 <ul class=
"small-gap">
139 <li><a class=
"reference internal" href=
"#integer-comparison-instructions" id=
"id98">Integer Comparison Instructions
</a></li>
140 <li><a class=
"reference internal" href=
"#floating-point-comparison-instructions" id=
"id99">Floating Point Comparison Instructions
</a></li>
143 <li><p class=
"first"><a class=
"reference internal" href=
"#vector-instructions" id=
"id100">Vector Instructions
</a></p>
144 <ul class=
"small-gap">
145 <li><a class=
"reference internal" href=
"#insert-element-instruction" id=
"id101">Insert Element Instruction
</a></li>
146 <li><a class=
"reference internal" href=
"#extract-element-instruction" id=
"id102">Extract Element Instruction
</a></li>
149 <li><p class=
"first"><a class=
"reference internal" href=
"#other-instructions" id=
"id103">Other Instructions
</a></p>
150 <ul class=
"small-gap">
151 <li><a class=
"reference internal" href=
"#forward-type-declaration" id=
"id104">Forward Type Declaration
</a></li>
152 <li><a class=
"reference internal" href=
"#phi-instruction" id=
"id105">Phi Instruction
</a></li>
153 <li><a class=
"reference internal" href=
"#select-instruction" id=
"id106">Select Instruction
</a></li>
154 <li><p class=
"first"><a class=
"reference internal" href=
"#call-instructions" id=
"id107">Call Instructions
</a></p>
155 <ul class=
"small-gap">
156 <li><a class=
"reference internal" href=
"#direct-procedure-call" id=
"id108">Direct Procedure Call
</a></li>
157 <li><a class=
"reference internal" href=
"#direct-function-call" id=
"id109">Direct Function Call
</a></li>
158 <li><a class=
"reference internal" href=
"#indirect-procedure-call" id=
"id110">Indirect Procedure Call
</a></li>
159 <li><a class=
"reference internal" href=
"#indirect-function-call" id=
"id111">Indirect Function Call
</a></li>
164 <li><a class=
"reference internal" href=
"#memory-blocks-and-alignment" id=
"id112">Memory Blocks and Alignment
</a></li>
165 <li><a class=
"reference internal" href=
"#intrinsic-functions" id=
"id113">Intrinsic Functions
</a></li>
166 <li><p class=
"first"><a class=
"reference internal" href=
"#support-functions" id=
"id114">Support Functions
</a></p>
167 <ul class=
"small-gap">
168 <li><a class=
"reference internal" href=
"#signrotate" id=
"id115">SignRotate
</a></li>
169 <li><a class=
"reference internal" href=
"#absoluteindex" id=
"id116">AbsoluteIndex
</a></li>
170 <li><a class=
"reference internal" href=
"#relativeindex" id=
"id117">RelativeIndex
</a></li>
171 <li><a class=
"reference internal" href=
"#abbrevindex" id=
"id118">AbbrevIndex
</a></li>
172 <li><a class=
"reference internal" href=
"#log2" id=
"id119">Log2
</a></li>
173 <li><a class=
"reference internal" href=
"#bitsizeof" id=
"id120">BitSizeOf
</a></li>
174 <li><a class=
"reference internal" href=
"#underlyingtype" id=
"id121">UnderlyingType
</a></li>
175 <li><a class=
"reference internal" href=
"#underlyingcount" id=
"id122">UnderlyingCount
</a></li>
176 <li><a class=
"reference internal" href=
"#isinteger" id=
"id123">IsInteger
</a></li>
177 <li><a class=
"reference internal" href=
"#isfloat" id=
"id124">IsFloat
</a></li>
178 <li><a class=
"reference internal" href=
"#isvector" id=
"id125">IsVector
</a></li>
179 <li><a class=
"reference internal" href=
"#isprimitive" id=
"id126">IsPrimitive
</a></li>
180 <li><a class=
"reference internal" href=
"#isfcnargtype" id=
"id127">IsFcnArgType
</a></li>
183 <li><p class=
"first"><a class=
"reference internal" href=
"#abbreviations" id=
"id128">Abbreviations
</a></p>
184 <ul class=
"small-gap">
185 <li><a class=
"reference internal" href=
"#abbreviations-block" id=
"id129">Abbreviations Block
</a></li>
186 <li><a class=
"reference internal" href=
"#todo" id=
"id130">TODO
</a></li>
191 </div><h2 id=
"introduction">Introduction
</h2>
192 <p>This document is a reference manual for the contents of PNaCl bitcode files. We
193 define bitcode files via three layers. The first layer is presented using
194 assembly language
<em>PNaClAsm
</em>, and defines the textual form of the bitcode
195 file. The textual form is then lowered to a sequence of
<a class=
"reference internal" href=
"#link-for-pnacl-records"><em>PNaCl
196 records
</em></a>. The final layer applies abbreviations that
197 convert each PNaCl record into a corresponding sequence of bits.
</p>
198 <img alt=
"/native-client/images/PNaClBitcodeFlow.png" src=
"/native-client/images/PNaClBitcodeFlow.png" />
199 <p>PNaClAsm uses a
<em>static single assignment
</em> (SSA) based representation that
200 requires generated results to have a single (assignment) source.
</p>
201 <p>PNaClAsm focuses on the semantic content of the file, not the bit-encoding of
202 that content. However, it does provide annotations that allow one to specify how
203 the
<a class=
"reference internal" href=
"#link-for-abbreviations-section"><em>abbreviations
</em></a> are used to convert
204 PNaCl records into the sequence of bits.
</p>
205 <p>Each construct in PNaClAsm defines a corresponding
<a class=
"reference internal" href=
"#link-for-pnacl-records"><em>PNaCl
206 record
</em></a>. A PNaCl bitcode file is simply a sequence of
207 PNaCl records. The goal of PNaClAsm is to make records easier to read, and not
208 to define a high-level user programming language.
</p>
209 <p>PNaCl records are an abstract encoding of structured data, similar to XML. Like
210 XML, A PNaCl record has a notion of a tag (i.e. the first element in a record,
211 called a
<em>code
</em>). PNaCl records can be nested. Nesting is defined by a
212 corresponding
<a class=
"reference internal" href=
"#link-for-enter-block-record-section"><em>enter
</em></a> and
213 <a class=
"reference internal" href=
"#link-for-exit-block-record-section"><em>exit
</em></a> block record.
</p>
214 <p>These block records must be used like balanced parentheses to define the block
215 structure that is imposed on top of records. Each exit record must be preceded
216 by a corresponding enter record. Blocks can be nested by nesting enter/exit
217 records appropriately.
</p>
218 <p>The
<em>PNaCl bitcode writer
</em> takes the sequence of records, defined by a PNaClAsm
219 program, and converts each record into a (variable-length) sequence of bits. The
220 output of each bit sequence is appended together. The resulting generated
221 sequence of bits is the contents of the PNaCl bitcode file.
</p>
222 <p>For every kind of record, there is a method for converting records into bit
223 sequences. These methods correspond to a notion of
224 <a class=
"reference internal" href=
"#link-for-abbreviations-section"><em>abbreviations
</em></a>. Each abbreviation defines
225 a specific bit sequence conversion to be applied.
</p>
226 <p>Abbreviations can be user-defined, but there are also predefined defaults. All
227 user-specified abbreviations are included in the generated bitcode
228 file. Predefined defaults are not.
</p>
229 <p>Each abbreviation defines how a record is converted to a bit sequence. The
230 <a class=
"reference internal" href=
"/native-client/overview.html#link-for-pnacl-translator"><em>PNaCl translator
</em></a> uses these abbreviations
231 to convert the bit sequence back to the corresponding sequence of PNaCl records.
232 As a result, all records have an abbreviation (user or default) associated with
234 <p>Conceptually, abbreviations are used to define how to pack the contents of
235 records into bit sequences. The main reason for defining abbreviations is to
236 save space. The default abbreviations are simplistic and are intended to handle
237 all possible records. The default abbreviations do not really worry about being
238 efficient, in terms of the number of bits generated.
</p>
239 <p>By separating the concepts of PNaCl records and abbreviations, the notion of
240 data compression is cleanly separated from semantic content. This allows
241 different use cases to decide how much effort should be spent on compressing
243 <p>For a JIT compiler that produces bitcode, little (if any) compression should be
244 applied. In fact, the API to the JIT may just be the records themselves. The
245 goal of a JIT is to perform the final translation to machine code as quickly as
247 <p>On the other hand, when delivering across the web, one may want to compress the
248 sequence of bits considerably, to reduce costs in delivering web pages. Note
249 that
<a class=
"reference internal" href=
"/native-client/devguide/devcycle/building.html#pnacl-compress"><em>pnacl-compress
</em></a> is provided as part of the SDK to do
251 <h2 id=
"data-model">Data Model
</h2>
252 <p>The data model for PNaCl bitcode is fixed at little-endian ILP32: pointers are
253 32 bits in size.
64-bit integer types are also supported natively via the i64
254 type (for example, a front-end can generate these from the C/C++ type
<code>long
256 <p>Integers are assumed to be modeled using two
’s complement. Floating point
257 support is fixed at
<a class=
"reference internal" href=
"/native-client/reference/pnacl-c-cpp-language-support.html#c-cpp-floating-point"><em>IEEE
754</em></a> 32-bit and
64-bit
258 values (float and double, respectively).
</p>
259 <h2 id=
"pnacl-blocks">PNaCl Blocks
</h2>
260 <p>Blocks are used to organize records in the bitcode file. The kinds of blocks
261 defined in PNaClAsm are:
</p>
262 <dl class=
"docutils">
263 <dt>Module block
</dt>
264 <dd>A top-level block defining the program. The
<a class=
"reference internal" href=
"#link-for-module-block"><em>module
265 block
</em></a> defines global information used by the program,
266 followed by function blocks defining the implementation of functions within
267 the program. All other blocks (listed below) must appear within a module
270 <dd>The
<a class=
"reference internal" href=
"#link-for-types-block-section"><em>types block
</em></a> defines the set of types
271 used by the program. All types used in the program must be defined in the
272 types block. These types consist of primitive types as well as high level
273 constructs such as vectors and function signatures.
</dd>
274 <dt>Globals block
</dt>
275 <dd>The
<a class=
"reference internal" href=
"#link-for-globals-block-section"><em>globals block
</em></a> defines the set of
276 addresses of global variables and constants used by the program. It also
277 defines how each global (associated with the global address) is initialized.
</dd>
278 <dt>Valuesymtab block
</dt>
279 <dd>The
<a class=
"reference internal" href=
"#link-for-valuesymtab-block-section"><em>valuesymtab block
</em></a> defines
280 textual names for external function addresses.
</dd>
281 <dt>Function block
</dt>
282 <dd>Each function (implemented) in a program has its own
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function
283 block
</em></a> that defines the implementation of
284 the corresponding function.
</dd>
285 <dt>Constants block
</dt>
286 <dd>Each implemented function that uses constants in its instructions defines a
287 <a class=
"reference internal" href=
"#link-for-constants-block-section"><em>constants block
</em></a>. Constants blocks
288 appear within the corresponding function block of the implemented function.
</dd>
289 <dt>Abbreviations block
</dt>
290 <dd>Defines global abbreviations that are used to compress PNaCl records. The
291 <a class=
"reference internal" href=
"#link-for-abbreviations-block-section"><em>abbreviations block
</em></a> is segmented
292 into multiple sections, one section for each kind of block. This block appears
293 at the beginning of the module block.
</dd>
295 <p>This section is only intended as a high-level discussion of blocks. Later
296 sections will dive more deeply into the constraints on how blocks must be laid
297 out. This section only presents the overall concepts of what kinds of data are
298 stored in each of the blocks.
</p>
299 <p>A PNaCl program consists of a
<a class=
"reference internal" href=
"#link-for-header-record-section"><em>header
300 record
</em></a> and a
<a class=
"reference internal" href=
"#link-for-module-block"><em>module
301 block
</em></a>. The header record defines a sequence of bytes
302 uniquely identifying the file as a bitcode file. The module block defines the
304 <p>Each block, within a bitcode file, defines values. These values are associated
305 with IDs. Each type of block defines different kinds of IDs. The
306 <a class=
"reference internal" href=
"#link-for-module-block"><em>module
</em></a>,
307 <a class=
"reference internal" href=
"#link-for-types-block-section"><em>types
</em></a>,
308 <a class=
"reference internal" href=
"#link-for-globals-block-section"><em>globals
</em></a>, and
309 <a class=
"reference internal" href=
"#link-for-abbreviations-block-section"><em>abbreviations
</em></a> blocks define global
310 identifiers, and only a single instance can appear. The
311 <a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function
</em></a> and
312 <a class=
"reference internal" href=
"#link-for-constants-block-section"><em>constant
</em></a> blocks define local
313 identifiers, and can have multiple instances (one for each implemented
315 <p>The only records in the module block that define values, are
<a class=
"reference internal" href=
"#link-for-function-address-section"><em>function
316 address
</em></a> records. Each function address
317 record defines a different function address, and the
<a class=
"reference internal" href=
"#link-for-function-type"><em>type
318 signature
</em></a> associated with that function address.
</p>
319 <p>Each
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function block
</em></a> defines the
320 implementation of a single function. Each function block defines the
321 intermediate representation of the function, consisting of basic blocks and
322 instructions. If constants are used within instructions, they are defined in a
323 <a class=
"reference internal" href=
"#link-for-constants-block-section"><em>constants block
</em></a>, nested within the
324 corresponding function block.
</p>
325 <p>All function blocks are associated with a corresponding function address. This
326 association is positional rather than explicit. That is, the Nth function block
327 in a module block corresponds to the Nth
328 <a class=
"reference internal" href=
"#link-for-function-address-section"><em>defining
</em></a> (rather than declared)
329 function address record in the module block.
</p>
330 <p>Hence, within a function block, there is no explicit reference to the function
331 address the block defines. For readability, PNaClAsm uses the corresponding
332 function signature, associated with the corresponding function address record,
333 even though that data does not appear in the corresponding records.
</p>
334 <h2 id=
"pnacl-records"><span id=
"link-for-pnacl-records"></span>PNaCl Records
</h2>
335 <p>A PNaCl record is a non-empty sequence of unsigned,
64-bit, integers. A record
336 is identified by the record
<em>code
</em>, which is the first element in the
337 sequence. Record codes are unique within a specific kind of block, but are not
338 necessarily unique across different kinds of blocks. The record code acts as the
339 variant discriminator (i.e. tag) within a block, to identify what kind of record
341 <p>Record codes that are local to a specific kind of block are small values
342 (starting from zero). In an ideal world, they would be a consecutive sequence of
343 integers, starting at zero. However, the reality is that PNaCl records evolved
344 over time (and actually started as
<a class=
"reference external" href=
"http://llvm.org/docs/BitCodeFormat.html">LLVM records
</a>). For backward compatibility,
345 obsolete numbers have not been reused, leaving gaps in the actual record code
347 <p>Global record codes are record codes that have the same meaning in multiple
348 kinds of blocks. To separate global record codes from local record codes, large
349 values are used. Currently there are four
<a class=
"reference internal" href=
"#link-for-global-record-codes"><em>global record
350 codes
</em></a>. To make these cases clear, and to leave
351 ample room for future growth in PNaClAsm, these special records have record
352 codes close to the value
2<sup>16</sup>. Note: Well-formed PNaCl bitcode files
353 do not have record codes
>=
2<sup>16</sup>.
</p>
354 <p>A PNaCl record is denoted as follows:
</p>
355 <pre class=
"prettyprint">
356 a:
<v0, v1, ... , vN
>
358 <p>The value
<code>v0
</code> is the record code. The remaining values,
<code>v1
</code> through
359 <code>vN
</code>, are parameters that fill in additional information needed by the
360 construct it represents. All records must have a record code. Hence, empty PNaCl
361 records are not allowed.
<code>a
</code> is the index to the abbreviation used to convert
362 the record to a bit sequence.
</p>
363 <p>While most records (for a given record code) have the same length, it is not
364 true of all record codes. Some record codes can have arbitrary length. In
365 particular, function type signatures, call instructions, phi instructions,
366 switch instructions, and global variable initialization records all have
367 variable length. The expected length is predefined and part of the PNaClAsm
368 language. See the corresponding construct (associated with the record) to
369 determine the expected length.
</p>
370 <p>The
<em>PNaCl bitstream writer
</em>, which converts records to bit sequences, does
371 this by writing out the abbreviation index used to encode the record, followed
372 by the contents of the record. The details of this are left to the section on
373 <a class=
"reference internal" href=
"#link-for-abbreviations-section"><em>abbreviations
</em></a>. However, at the record
374 level, one important aspect of this appears in
<a class=
"reference internal" href=
"#link-for-enter-block-record-section"><em>block
375 enter
</em></a> records. These records must define
376 how many bits are required to hold abbreviation indices associated with records
378 <h2 id=
"default-abbreviations"><span id=
"link-for-default-abbreviations"></span>Default Abbreviations
</h2>
379 <p>There are
4 predefined (default) abbreviation indices, used as the default
380 abbreviations for PNaCl records. They are:
</p>
381 <dl class=
"docutils">
383 <dd>Abbreviation index for the abbreviation used to bit-encode an exit block
386 <dd>Abbreviation index for the abbreviation used to bit-encode an enter block
389 <dd>Abbreviation index for the abbreviation used to bit-encode a user-defined
390 abbreviation. Note: User-defined abbreviations are also encoded as records,
391 and hence need an abbreviation index to bit-encode them.
</dd>
393 <dd>Abbreviation index for the default abbreviation to bit-encode all other
394 records in the bitcode file.
</dd>
396 <p>A block may, in addition, define a list of block specific, user-defined,
397 abbreviations (of length
<code>U
</code>). The number of bits
<code>B
</code> specified for an enter
398 record must be sufficiently large such that:
</p>
399 <pre class=
"prettyprint">
402 <p>In addition, the upper limit for
<code>B
</code> is
<code>16</code>.
</p>
403 <p>PNaClAsm requires specifying the number of bits needed to read abbreviations as
404 part of the enter block record. This allows the PNaCl bitcode reader/writer to
405 use the specified number of bits to encode abbreviation indices.
</p>
406 <h2 id=
"pnacl-identifiers">PNaCl Identifiers
</h2>
407 <p>A program is defined by a
<a class=
"reference internal" href=
"#link-for-module-block"><em>module block
</em></a>. Blocks can
408 be nested within other blocks, including the module block. Each block defines a
409 sequence of records.
</p>
410 <p>Most of the records, within a block, also define unique values. Each unique
411 value is given a corresponding unique identifier (i.e.
<em>ID
</em>). In PNaClAsm, each
412 kind of block defines its own kind of identifiers. The names of these
413 identifiers are defined by concatenating a prefix character (
<code>'
@'
</code> or
414 <code>'%'
</code>), the kind of block (a single character), and a suffix index. The suffix
415 index is defined by the positional location of the defined value within the
416 records of the corresponding block. The indices are all zero based, meaning that
417 the first defined value (within a block) is defined using index
0.
</p>
418 <p>Identifiers are categorized into two types,
<em>local
</em> and
<em>global
</em>. Local
419 identifiers are identifiers that are associated with the implementation of a
420 single function. In that sense, they are local to the block they appear in.
</p>
421 <p>All other identifiers are global, and can appear in multiple blocks. This split
422 is intentional. Global identifiers are used by multiple functions, and therefore
423 must be known in all function implementations. Local identifiers only apply to a
424 single function, and can be reused between functions. The
<a class=
"reference internal" href=
"/native-client/overview.html#link-for-pnacl-translator"><em>PNaCl
425 translator
</em></a> uses this separation to parallelize the
426 compilation of functions.
</p>
427 <p>Note that local abbreviation identifiers are unique to the block they appear
428 in. Global abbreviation identifiers are only unique to the block type they are
429 defined for. Different block types can reuse global abbreviation identifiers.
</p>
430 <p>Global identifiers use the prefix character
<code>'
@'
</code> while local identifiers use
431 the prefix character
<code>'%'
</code>.
</p>
432 <p>Note that by using positional location to define identifiers (within a block),
433 the values defined in PNaCl bitcode files need not be explicitly included in the
434 bitcode file. Rather, they are inferred by the (ordered) position of the record
435 in the block. This is also intentional. It is used to reduce the amount of data
436 that must be (explicitly) passed to the
<a class=
"reference internal" href=
"/native-client/overview.html#link-for-pnacl-translator"><em>PNaCl
437 translator
</em></a>, when downloaded into Chrome.
</p>
438 <p>In general, most of the records within blocks are assumed to be topologically
439 sorted, putting value definitions before their uses. This implies that records
440 do not need to encode data if they can deduce the corresponding information from
442 <p>The most common use of this is that many instructions use the type of their
443 operands to determine the type of the instruction. Again, this is
444 intentional. It allows less information to be stored.
</p>
445 <p>However, for function blocks (which define instructions), a topological sort may
446 not exist. Loop carried value dependencies simply do not allow topologically
447 sorting. To deal with this, function blocks have a notion of (instruction value)
448 <a class=
"reference internal" href=
"#link-for-forward-type-declaration-section"><em>forward type
449 declarations
</em></a>. These declarations
450 must appear before any of the uses of that value, if the (instruction) value is
451 defined later in the function than its first use.
</p>
452 <p>The kinds of identifiers used in PNaClAsm are:
</p>
453 <dl class=
"docutils">
455 <dd>Global abbreviation identifier.
</dd>
457 <dd>Local abbreviation identifier.
</dd>
459 <dd>Function basic block identifier.
</dd>
461 <dd>Function constant identifier.
</dd>
463 <dd>Global function address identifier.
</dd>
465 <dd>Global variable/constant address identifier.
</dd>
467 <dd>Function parameter identifier.
</dd>
469 <dd>Global type identifier.
</dd>
471 <dd>Value generated by an instruction in a function block.
</dd>
473 <h2 id=
"conventions-for-describing-records">Conventions For Describing Records
</h2>
474 <p>PNaClAsm is the textual representation of
<a class=
"reference internal" href=
"#link-for-pnacl-records"><em>PNaCl
475 records
</em></a>. Each PNaCl record is described by a
476 corresponding PNaClAsm construct. These constructs are described using syntax
477 rules, and semantics on how they are converted to records. Along with the rules,
478 is a notion of
<a class=
"reference internal" href=
"#link-for-global-state-section"><em>global state
</em></a>. The global
479 state is updated by syntax rules. The purpose of the global state is to track
480 positional dependencies between records.
</p>
481 <p>For each PNaCl construct, we define multiple sections. The
<strong>Syntax
</strong>
482 section defines a syntax rule for the construct. The
<strong>Record
</strong> section
483 defines the corresponding record associated with the syntax rule. The
484 <strong>Semantics
</strong> section describes the semantics associated with the record, in
485 terms of data within the global state and the corresponding syntax. It also
486 includes other high-level semantics, when appropriate.
</p>
487 <p>The
<strong>Constraints
</strong> section (if present) defines any constraints associated
488 with the construct, including the global state. The
<strong>Updates
</strong> section (if
489 present) defines how the global state is updated when the construct is
490 processed. The
<strong>Examples
</strong> section gives one or more examples of using the
491 corresponding PNaClAsm construct.
</p>
492 <p>Some semantics sections use functions to compute values. The meaning of
493 functions can be found in
<a class=
"reference internal" href=
"#link-for-support-functions-section"><em>support
494 functions
</em></a>.
</p>
495 <p>The syntax rule may include the
496 <a class=
"reference internal" href=
"#link-for-abbreviations-section"><em>abbreviation
</em></a> to use, when converting to a
497 bit-sequence. These abbreviations, if allowed, are at the end of the construct,
498 and enclosed in
<code><</code> and
<code>></code> brackets. These abbreviations are optional in
499 the syntax, and can be omitted. If they are used, the abbreviation brackets are
500 part of the actual syntax of the construct. If the abbreviation is omitted, the
501 default abbreviation index is used. To make it clear that abbreviations are
502 optional, syntax rules separate abbreviations using plenty of whitespace.
</p>
503 <p>Within a syntax rule, lower case characters are literal values. Sequences of
504 upper case alphanumeric characters are named values. If we mix lower and upper
505 case letters within a name appearing in a syntax rule, the lower case letters
506 are literal while the upper case sequence of alphanumeric characters denote rule
507 specific values. The valid values for each of these names will be defined in
508 the corresponding semantics and constraints subsections.
</p>
509 <p>For example, consider the following syntax rule:
</p>
510 <pre class=
"prettyprint">
511 %vN = add T O1, O2;
<A
>
513 <p>This rule defines a PNaClAsm add instruction. This construct defines an
514 instruction that adds two values (
<code>O1
</code> and
<code>O2
</code>) to generate instruction
515 value
<code>%vN
</code>. The types of the arguments, and the result, are all of type
516 <code>T
</code>. If abbreviation ID
<code>A
</code> is present, the record is encoded using that
517 abbreviation. Otherwise the corresponding
<a class=
"reference internal" href=
"#link-for-default-abbreviations"><em>default abbreviation
518 index
</em></a> is used.
</p>
519 <p>To be concrete, the syntactic rule above defines the structure of the following
520 PNaClAsm examples:
</p>
521 <pre class=
"prettyprint">
522 %v10 = add i32 %v1, %v2;
<@a5
>
523 %v11 = add i32 %v10, %v3;
525 <p>In addition to specifying the syntax, each syntax rule can also also specify the
526 contents of the corresponding record in the corresponding record subsection. In
527 simple cases, the elements of the corresponding record are predefined (literal)
528 constants. Otherwise the record element is an identifier from another subsection
529 associated with the construct.
</p>
530 <h2 id=
"factorial-example">Factorial Example
</h2>
531 <p>This section provides a simple example of a PNaCl bitcode file. Its contents
532 describe a bitcode file that only defines a function to compute the factorial
533 value of a number.
</p>
534 <p>In C, the factorial function can be defined as:
</p>
535 <pre class=
"prettyprint">
537 if (n ==
1) return
1;
538 return n * fact(n-
1);
541 <p>Compiling this into a PNaCl bitcode file, and dumping out its contents with
542 utility
<a class=
"reference internal" href=
"/native-client/devguide/devcycle/building.html#pnacl-bcdis"><em>pnacl-bcdis
</em></a>, the corresponding output is:
</p>
543 <pre class=
"prettyprint">
544 0:
0|
<65532,
80,
69,
88,
69,
1,
0,|Magic Number: 'PEXE' (
80,
69,
88,
69)
545 |
8,
0,
17,
0,
4,
0,
2,
0,
0, |PNaCl Version:
2
547 16:
0|
1:
<65535,
8,
2> |module { // BlockID =
8
548 24:
0|
3:
<1,
1> | version
1;
549 26:
4|
1:
<65535,
0,
2> | abbreviations { // BlockID =
0
550 36:
0|
0:
<65534> | }
551 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
552 48:
0|
3:
<1,
4> | count
4;
553 50:
4|
3:
<7,
32> |
@t0 = i32;
554 53:
6|
3:
<2> |
@t1 = void;
555 55:
4|
3:
<21,
0,
0,
0> |
@t2 = i32 (i32);
556 59:
4|
3:
<7,
1> |
@t3 = i1;
557 62:
0|
0:
<65534> | }
558 64:
0|
3:
<8,
2,
0,
0,
0> | define external i32
@f0(i32);
559 68:
6|
1:
<65535,
19,
2> | globals { // BlockID =
19
560 76:
0|
3:
<5,
0> | count
0;
561 78:
4|
0:
<65534> | }
562 80:
0|
1:
<65535,
14,
2> | valuesymtab { // BlockID =
14
563 88:
0|
3:
<1,
0,
102,
97,
99, |
@f0 :
"fact
";
565 96:
4|
0:
<65534> | }
566 100:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0) {
568 108:
0|
3:
<1,
3> | blocks
3;
569 110:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
570 120:
0|
3:
<1,
0> | i32:
571 122:
4|
3:
<4,
2> | %c0 = i32
1;
572 125:
0|
0:
<65534> | }
574 128:
0|
3:
<28,
2,
1,
32> | %v0 = icmp eq i32 %p0, %c0;
575 132:
6|
3:
<11,
1,
2,
1> | br i1 %v0, label %b1, label %b2;
577 136:
6|
3:
<10,
2> | ret i32 %c0;
579 139:
2|
3:
<2,
3,
2,
1> | %v1 = sub i32 %p0, %c0;
580 143:
2|
3:
<34,
0,
5,
1> | %v2 = call i32
@f0(i32 %v1);
581 148:
0|
3:
<2,
5,
1,
2> | %v3 = mul i32 %p0, %v2;
582 152:
0|
3:
<10,
1> | ret i32 %v3;
583 154:
4|
0:
<65534> | }
584 156:
0|
0:
<65534> |}
586 <p>Note that there are three columns in this output. The first column contains the
587 bit positions of the records within the bitcode file. The second column contains
588 the sequence of records within the bitcode file. The third column contains the
589 corresponding PNaClAsm program.
</p>
590 <p>Bit positions are defined by a pair
<code>B:N
</code>.
<code>B
</code> is the number of bytes, while
591 <code>N
</code> is the bit offset within the
<code>B
</code>-th byte. Hence, the bit position (in
593 <pre class=
"prettyprint">
596 <p>Hence, the first record is at bit offset
<code>0</code> (
<code>0*
8+
0</code>). The second record is
597 at bit offset
<code>128</code> (
<code>16*
8+
0</code>). The third record is at bit offset
<code>192</code>
598 (
<code>24*
8+
0</code>). The fourth record is at bit offset
<code>212</code> (
<code>26*
8+
4</code>).
</p>
599 <p>The
<a class=
"reference internal" href=
"#link-for-header-record-section"><em>header record
</em></a> is a sequence of
16
600 bytes, defining the contents of the first
16 bytes of the bitcode file. These
601 bytes never change, and are expected for all version
2, PNaCl bitcode files. The
602 first four bytes define the magic number of the file, i.e.
‘PEXE
’. All PEXE
603 bitcode files begin with these four bytes.
</p>
604 <p>All but the header record has an abbreviation index associated with it. Since no
605 user-defined abbreviations are provided, all records were converted to
606 bit sequences using default abbreviations.
</p>
607 <p>The types block (starting at bit address
<code>40:
0</code>), defines
4 types:
<code>i1
</code>,
608 <code>i32
</code>,
<code>void
</code>, and function signature
<code>i32 (i32)
</code>.
</p>
609 <p>Bit address
<code>64:
0</code> declares the factorial function address
<code>@f0
</code>, and its
610 corresponding type signature. Bit address
<code>88:
0</code> associates the name
<code>fact
</code>
611 with function address
<code>@f0
</code>.
</p>
612 <p>Bit address
<code>100:
0</code> defines the function block that implements function
613 <code>fact
</code>. The entry point is
<code>%b0
</code> (at bit address
<code>128:
0</code>). It uses the
614 32-bit integer constant
<code>1</code> (defined at bit addresses
<code>122:
4</code>). Bit address
615 <code>128:
0</code> defines an equality comparison of the argument
<code>%p0
</code> with
<code>1</code>
616 (constant
<code>%c0
</code>). Bit address
<code>132:
6</code> defines a conditional branch. If the
617 result of the previous comparison (
<code>%v0
</code>) is true, the program will branch to
618 block
<code>%b1
</code>. Otherwise it will branch to block
<code>%b2
</code>.
</p>
619 <p>Bit address
<code>136:
6</code> returns constant
<code>1</code> (
<code>%c0
</code>) when the input parameter
620 is
1. Instructions between bit address
<code>139:
2</code> and
<code>154:
4</code> compute and
621 return
<code>n * fact(n-
1)
</code>.
</p>
622 <h2 id=
"road-map">Road Map
</h2>
623 <p>At this point, this document transitions from basic concepts to the details
624 of how records should be formatted. This section defines the road map to
625 the remaining sections in this document.
</p>
626 <p>Many records have implicit information associated with them, and must be
627 maintained across records.
<a class=
"reference internal" href=
"#link-for-global-state-section"><em>Global state
</em></a>
628 describes how this implicit information is modeled. In addition, there are
629 various
<a class=
"reference internal" href=
"#link-for-support-functions-section"><em>support functions
</em></a> that are
630 used to define the semantics of records, and how they update the global state.
</p>
631 <p>There are just a handful of global records (records that either don
’t appear in
632 any block, or can appear in all blocks).
<a class=
"reference internal" href=
"#link-for-global-record-codes"><em>Global
633 records
</em></a> describes these records. This includes
634 the block delimiter records
<a class=
"reference internal" href=
"#link-for-enter-block-record-section"><em>enter
</em></a>
635 and
<a class=
"reference internal" href=
"#link-for-exit-block-record-section"><em>exit
</em></a> that define block
637 <p>PNaClAsm is a strongly typed language, and most block values are typed.
638 <a class=
"reference internal" href=
"#link-for-types-block-section"><em>types
</em></a> describes the set of legal types, and
639 how to define types.
</p>
640 <p>Global variables and their initializers are presented in the
<a class=
"reference internal" href=
"#link-for-globals-block-section"><em>globals
641 block
</em></a>.
<a class=
"reference internal" href=
"#link-for-function-address-section"><em>Function
642 addresses
</em></a> are part of the
<a class=
"reference internal" href=
"#link-for-module-block"><em>module
643 block
</em></a>, but must be defined before any global variables.
</p>
644 <p>Names to be associated with global variables and function addresses, are defined
645 in the
<a class=
"reference internal" href=
"#link-for-valuesymtab-block-section"><em>valuesymtab block
</em></a>, and must
646 appear after the
<a class=
"reference internal" href=
"#link-for-globals-block-section"><em>globals block
</em></a>, but
647 before any
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function definition
</em></a>.
</p>
648 <p>The
<a class=
"reference internal" href=
"#link-for-module-block"><em>module block
</em></a> is the top-most block, and all
649 other blocks must appear within the module block. The module block defines the
650 executable in the bitcode file.
</p>
651 <p>Constants used within a
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function
652 definition
</em></a> must be defined using a
653 <a class=
"reference internal" href=
"#link-for-constants-block-section"><em>constants block
</em></a>. Each function
654 definition is defined by a
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function
655 block
</em></a> and constant blocks can only appear
656 within function blocks. Constants defined within a constant block can only be
657 used in the enclosing function block.
</p>
658 <p>Function definitions are defined by a sequence of instructions. There are
659 several types of instructions.
</p>
660 <p>A
<a class=
"reference internal" href=
"#link-for-terminator-instruction-section"><em>terminator instruction
</em></a> is the
661 last instruction in a
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>basic block
</em></a>, and
662 is a branch, return, or unreachable instruction.
</p>
663 <p>There are
<a class=
"reference internal" href=
"#link-for-integer-binary-instructions"><em>integer
</em></a> and
664 <a class=
"reference internal" href=
"#link-for-floating-point-binary-instructions"><em>floating point
</em></a> binary
665 operations. Integer binary instructions include both arithmetic and logical
666 operations. Floating point instructions define arithmetic operations.
</p>
667 <p>There are also
<a class=
"reference internal" href=
"#link-for-memory-creation-and-access-instructions"><em>memory
668 access
</em></a> instructions that
669 allow one to load and store values. That section also includes how to define
670 local variables using the
<a class=
"reference internal" href=
"#link-for-alloca-instruction"><em>alloca
671 instruction
</em></a>.
</p>
672 <p>One can also convert integer and floating point values using
<a class=
"reference internal" href=
"#link-for-conversion-instructions"><em>conversion
673 instructions
</em></a>.
</p>
674 <p><a class=
"reference internal" href=
"#link-for-compare-instructions"><em>Comparison instructions
</em></a>
675 allow you to compare values.
</p>
676 <p><a class=
"reference internal" href=
"#link-for-vector-instructions"><em>Vector instructions
</em></a> allow you to build and
677 update vectors. Corresponding
<a class=
"reference internal" href=
"#link-for-intrinsic-functions-section"><em>intrinsic
678 functions
</em></a>, as well as
679 <a class=
"reference internal" href=
"#link-for-integer-binary-instructions"><em>integer
</em></a> and
<a class=
"reference internal" href=
"#link-for-floating-point-binary-instructions"><em>floating
680 point
</em></a> binary instructions allow
681 you to apply operations to vectors.
</p>
682 <p>In addition,
<a class=
"reference internal" href=
"#link-for-other-pnaclasm-instructions"><em>other instructions
</em></a> are
683 available. This includes function and procedure calls.
</p>
684 <p>There are also
<a class=
"reference internal" href=
"#link-for-memory-blocks-and-alignment-section"><em>memory
685 alignment
</em></a> issues that should be
686 considered for global and local variables, as well as load and store
688 <p>Finally, how to pack records is described in the
689 <a class=
"reference internal" href=
"#link-for-abbreviations-section"><em>abbreviations
</em></a> section.
</p>
690 <h2 id=
"global-state"><span id=
"link-for-global-state-section"></span>Global State
</h2>
691 <p>This section describes the global state associated with PNaClAsm. It is used to
692 define contextual data that is carried between records.
</p>
693 <p>In particular, PNaClAsm is a strongly typed language, and hence, we must track
694 the type associated with values. Subsection
<a class=
"reference internal" href=
"#link-to-typing-functions"><em>Typing Functions
</em></a>
695 describes the functions used to maintain typing information associated with
697 <p>Values are implicitly ordered within a block, and the indices associated with
698 the values do not appear in records. Rather, ID counters are used to figure out
699 what corresponding ID name is associated with a value generating record.
700 Subsection
<a class=
"reference internal" href=
"#link-to-id-counters"><em>ID Counters
</em></a> defines counters maintained in the global
702 <p>In several blocks, one of the first records in the block defines how many values
703 are defined in in the block. The main purpose of these counts is to communicate
704 to the
<a class=
"reference internal" href=
"/native-client/overview.html#link-for-pnacl-translator"><em>PNaCl translator
</em></a> space requirements, or
705 a limit so that it can detect bad references to values. Subsection
706 <a class=
"reference internal" href=
"#link-for-size-variables"><em>Size Variables
</em></a> defines variables that hold size definitions in
707 the corresponding records.
</p>
708 <p>Finally, the function and constants block contain implicit context between
709 records in those blocks. Subsection
<a class=
"reference internal" href=
"#link-to-other-variables"><em>Other Variables
</em></a> defines the
710 variables that contain this implicit context.
</p>
711 <h3 id=
"typing-functions"><span id=
"link-to-typing-functions"></span>Typing Functions
</h3>
712 <p>Associated with most identifiers is a type. This type defines what type the
713 corresponding value has. It is defined by the (initially empty) map:
</p>
714 <pre class=
"prettyprint">
715 TypeOf: ID -
> Type
717 <p>For each type in the
<a class=
"reference internal" href=
"#link-for-types-block-section"><em>types block
</em></a>, a
718 corresponding inverse map:
</p>
719 <pre class=
"prettyprint">
720 TypeID: Type -
> ID
722 <p>is maintained to convert syntactic types to the corresponding type ID.
</p>
723 <p>Note: This document assumes that map
<code>TypeID
</code> is automatically maintained
724 during updates to map
<code>TypeOf
</code> (when given a type
<code>ID
</code>). Hence,
<em>Updates
</em>
725 subsections will not contain assignments to this map.
</p>
726 <p>Associated with each function identifier is its
<a class=
"reference internal" href=
"#link-for-function-type"><em>type
727 signature
</em></a>. This is different than the type of the
728 function identifier, since function identifiers represent the function address
729 which is a pointer (and pointers are always implemented as a
32-bit integer
730 following the ILP32 data model).
</p>
731 <p>Function type signatures are maintained using:
</p>
732 <pre class=
"prettyprint">
733 TypeOfFcn: ID -
> Type
735 <p>In addition, if a function address has an implementing block, there is a
736 corresponding implementation associated with the function address. To indicate
737 which function addresses have implementations, we use the set:
</p>
738 <pre class=
"prettyprint">
739 DefiningFcnIDs: set(ID)
741 <h3 id=
"link-to-id-counters"><span id=
"id-counters"></span>ID Counters
</h3>
742 <p>Each block defines one or more kinds of values. Value indices are generated
743 sequentially, starting at zero. To capture this, the following counters are
745 <dl class=
"docutils">
747 <dd>The number of types defined so far (in the
<a class=
"reference internal" href=
"#link-for-types-block-section"><em>types
748 block
</em></a>).
</dd>
749 <dt>NumFuncAddresses
</dt>
750 <dd>The number of function addresses defined so far (in the
<a class=
"reference internal" href=
"#link-for-module-block"><em>module
751 block
</em></a>).
</dd>
752 <dt>NumGlobalAddresses
</dt>
753 <dd>The number of global variable/constant addresses defined so far (in the
754 <a class=
"reference internal" href=
"#link-for-globals-block-section"><em>globals block
</em></a>).
</dd>
756 <dd>The number of parameters defined for a function. Note: Unlike other counters,
757 this value is set once, at the beginning of the corresponding
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function
758 block
</em></a>, based on the type signature
759 associated with the function.
</dd>
760 <dt>NumFcnConsts
</dt>
761 <dd>The number of constants defined in a function so far (in the corresponding
762 nested
<a class=
"reference internal" href=
"#link-for-constants-block-section"><em>constants block
</em></a>).
</dd>
763 <dt>NumBasicBlocks
</dt>
764 <dd>The number of basic blocks defined so far (within a
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function
765 block
</em></a>).
</dd>
766 <dt>NumValuedInsts
</dt>
767 <dd>The number of instructions, generating values, defined so far (within a
768 <a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function block
</em></a>).
</dd>
770 <h3 id=
"size-variables"><span id=
"link-for-size-variables"></span>Size Variables
</h3>
771 <p>A number of blocks define expected sizes of constructs. These sizes are recorded
772 in the following size variables:
</p>
773 <dl class=
"docutils">
774 <dt>ExpectedBasicBlocks
</dt>
775 <dd>The expected
<a class=
"reference internal" href=
"#link-for-basic-blocks-count"><em>number of basic blocks
</em></a> within
776 a function implementation.
</dd>
777 <dt>ExpectedTypes
</dt>
778 <dd>The expected
<a class=
"reference internal" href=
"#link-for-types-count-record"><em>number of types
</em></a> defined in
779 the types block.
</dd>
780 <dt>ExpectedGlobals
</dt>
781 <dd>The expected
<a class=
"reference internal" href=
"#link-for-globals-count-record"><em>number of global variable/constant
782 addresses
</em></a> in the globals block.
</dd>
783 <dt>ExpectedInitializers
</dt>
784 <dd>The expected
<a class=
"reference internal" href=
"#link-for-compound-initializer"><em>number of initializers
</em></a> for
785 a global variable/constant address in the globals block.
</dd>
787 <p>It is assumed that the corresponding
<a class=
"reference internal" href=
"#link-to-id-counters"><em>ID counters
</em></a> are
788 always smaller than the corresponding size variables (except
789 ExpectedInitializers). That is:
</p>
790 <pre class=
"prettyprint">
791 NumBasicBlocks
< ExpectedBasicBlocks
792 NumTypes
< ExpectedTypes
793 NumGlobalAddresses
< ExpectedGlobals
795 <h3 id=
"other-variables"><span id=
"link-to-other-variables"></span>Other Variables
</h3>
796 <dl class=
"docutils">
797 <dt>EnclosingFcnID
</dt>
798 <dd>The function ID of the function block being processed.
</dd>
799 <dt>ConstantsSetType
</dt>
800 <dd>Holds the type associated with the last
<a class=
"reference internal" href=
"#link-for-constants-set-type-record"><em>set type
801 record
</em></a> in the constants block. Note: at
802 the beginning of each constants block, this variable is set to type void.
</dd>
804 <h2 id=
"global-records"><span id=
"link-for-global-record-codes"></span>Global Records
</h2>
805 <p>Global records are records that can appear in any block. These records have
806 the same meaning in multiple kinds of blocks.
</p>
807 <p>There are four global PNaCl records, each having its own record code. These
808 global records are:
</p>
809 <dl class=
"docutils">
811 <dd>The
<a class=
"reference internal" href=
"#link-for-header-record-section"><em>header record
</em></a> is the first record
812 of a PNaCl bitcode file, and identifies the file
’s magic number, as well as
813 the bitcode version it uses. The record defines the sequence of bytes that
814 make up the header and uniquely identifies the file as a PNaCl bitcode file.
</dd>
816 <dd>An
<a class=
"reference internal" href=
"#link-for-enter-block-record-section"><em>enter record
</em></a> defines the
817 beginning of a block. Since blocks can be nested, one can appear inside other
818 blocks, as well as at the top level.
</dd>
820 <dd>An
<a class=
"reference internal" href=
"#link-for-exit-block-record-section"><em>exit record
</em></a> defines the end of a
821 block. Hence, it must appear in every block, to end the block.
</dd>
822 <dt>Abbreviation
</dt>
823 <dd>An
<a class=
"reference internal" href=
"#link-for-abbreviation-record"><em>abbreviation record
</em></a> defines a
824 user-defined abbreviation to be applied to records within blocks.
825 Abbreviation records appearing in the abbreviations block define global
826 abbreviations. All other abbreviations are local to the block they appear in,
827 and can only be used in that block.
</dd>
829 <p>All global records can
’t have user-defined abbreviations associated with
830 them. The
<a class=
"reference internal" href=
"#link-for-default-abbreviations"><em>default abbreviation
</em></a> is always
832 <h3 id=
"header-record"><span id=
"link-for-header-record-section"></span>Header Record
</h3>
833 <p>The header record must be the first record in the file. It is the only record in
834 the bitcode file that doesn
’t have a corresponding construct in PNaClAsm. In
835 addition, no abbreviation index is associated with it.
</p>
836 <p><strong>Syntax
</strong>:
</p>
837 <p>There is no syntax for header records in PNaClAsm.
</p>
838 <p><strong>Record
</strong>:
</p>
839 <pre class=
"prettyprint">
840 <65532,
80,
69,
88,
69,
1,
0,
8,
0,
17,
0,
4,
0,
2,
0,
0,
0>
842 <p><strong>Semantics
</strong>:
</p>
843 <p>The header record defines the initial sequence of bytes that must appear at the
844 beginning of all (PNaCl bitcode version
2) files. That sequence is the list of
845 bytes inside the record (excluding the record code). As such, it uniquely
846 identifies all PNaCl bitcode files.
</p>
847 <p><strong>Examples
</strong>:
</p>
848 <pre class=
"prettyprint">
849 0:
0|
<65532,
80,
69,
88,
69,
1,
0,|Magic Number: 'PEXE' (
80,
69,
88,
69)
850 |
8,
0,
17,
0,
4,
0,
2,
0,
0, |PNaCl Version:
2
853 <h3 id=
"enter-block-record"><span id=
"link-for-enter-block-record-section"></span>Enter Block Record
</h3>
854 <p>Block records can be top-level, as well as nested in other blocks. Blocks must
855 begin with an
<em>enter
</em> record, and end with an
856 <a class=
"reference internal" href=
"#link-for-exit-block-record-section"><em>exit
</em></a> record.
</p>
857 <p><strong>Syntax
</strong>:
</p>
858 <pre class=
"prettyprint">
861 <p><strong>Record
</strong>:
</p>
862 <pre class=
"prettyprint">
863 1:
<65535, ID, B
>
865 <p><strong>Semantics
</strong>:
</p>
866 <p>Enter block records define the beginning of a block.
<code>B
</code>, if present, is the
867 number of bits needed to represent all possible abbreviation indices used within
868 the block. If omitted,
<code>B=
2</code> is assumed.
</p>
869 <p>The block
<code>ID
</code> value is dependent on the name
<code>N
</code>. Valid names and
870 corresponding
<code>BlockID
</code> values are defined as follows:
</p>
871 <table border=
"1" class=
"docutils">
874 <thead valign=
"bottom">
875 <tr class=
"row-odd"><th class=
"head">N
</th>
876 <th class=
"head">Block ID
</th>
880 <tr class=
"row-even"><td>abbreviations
</td>
883 <tr class=
"row-odd"><td>constants
</td>
886 <tr class=
"row-even"><td>function
</td>
889 <tr class=
"row-odd"><td>globals
</td>
892 <tr class=
"row-even"><td>module
</td>
895 <tr class=
"row-odd"><td>types
</td>
898 <tr class=
"row-even"><td>valuesymtab
</td>
903 <p>Note: For readability, PNaClAsm defines a more readable form of a function block
904 enter record. See
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function blocks
</em></a> for
906 <p><strong>Examples
</strong>:
</p>
907 <pre class=
"prettyprint">
908 16:
0|
1:
<65535,
8,
2> |module { // BlockID =
8
909 24:
0|
3:
<1,
1> | version
1;
910 26:
4|
1:
<65535,
0,
2> | abbreviations { // BlockID =
0
911 36:
0|
0:
<65534> | }
912 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
913 48:
0|
3:
<1,
2> | count
2;
914 50:
4|
3:
<2> |
@t0 = void;
915 52:
2|
3:
<21,
0,
0> |
@t1 = void ();
916 55:
4|
0:
<65534> | }
917 56:
0|
3:
<8,
1,
0,
1,
0> | declare external void
@f0();
918 60:
6|
1:
<65535,
19,
2> | globals { // BlockID =
19
919 68:
0|
3:
<5,
0> | count
0;
920 70:
4|
0:
<65534> | }
921 72:
0|
0:
<65534> |}
923 <h3 id=
"exit-block-record"><span id=
"link-for-exit-block-record-section"></span>Exit Block Record
</h3>
924 <p>Block records can be top-level, as well as nested, records. Blocks must begin
925 with an
<a class=
"reference internal" href=
"#link-for-enter-block-record-section"><em>enter
</em></a> record, and end with
926 an
<em>exit
</em> record.
</p>
927 <p><strong>Syntax
</strong>:
</p>
928 <pre class=
"prettyprint">
931 <p><strong>Record
</strong>:
</p>
932 <pre class=
"prettyprint">
935 <p><strong>Semantics
</strong>:
</p>
936 <p>All exit records are identical, no matter what block they are ending. An exit
937 record defines the end of the block.
</p>
938 <p><strong>Examples
</strong>:
</p>
939 <pre class=
"prettyprint">
940 16:
0|
1:
<65535,
8,
2> |module { // BlockID =
8
941 24:
0|
3:
<1,
1> | version
1;
942 26:
4|
1:
<65535,
0,
2> | abbreviations { // BlockID =
0
943 36:
0|
0:
<65534> | }
944 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
945 48:
0|
3:
<1,
2> | count
2;
946 50:
4|
3:
<2> |
@t0 = void;
947 52:
2|
3:
<21,
0,
0> |
@t1 = void ();
948 55:
4|
0:
<65534> | }
949 56:
0|
3:
<8,
1,
0,
1,
0> | declare external void
@f0();
950 60:
6|
1:
<65535,
19,
2> | globals { // BlockID =
19
951 68:
0|
3:
<5,
0> | count
0;
952 70:
4|
0:
<65534> | }
953 72:
0|
0:
<65534> |}
955 <h3 id=
"abbreviation-record"><span id=
"link-for-abbreviation-record"></span>Abbreviation Record
</h3>
956 <p>Abbreviation records define abbreviations. See
957 <a class=
"reference internal" href=
"#link-for-abbreviations-section"><em>abbreviations
</em></a> for details on how
958 abbreviations should be written. This section only presents the mechanical
959 details for converting an abbreviation into a PNaCl record.
</p>
960 <p><strong>Syntax
</strong>:
</p>
961 <pre class=
"prettyprint">
962 A = abbrev
<E1, ... , EM
>;
964 <p><strong>Record
</strong>:
</p>
965 <pre class=
"prettyprint">
966 2:
<65533, M, EE1, ... , EEM
>
968 <p><strong>Semantics
</strong>:
</p>
969 <p>Defines an abbreviation
<code>A
</code> as the sequence of encodings
<code>E1
</code> through
970 <code>EM
</code>. If the abbreviation appears within the
<a class=
"reference internal" href=
"#link-for-abbreviations-block-section"><em>abbreviations
971 block
</em></a>,
<code>A
</code> must be a global
972 abbreviation. Otherwise,
<code>A
</code> must be a local abbreviation.
</p>
973 <p>Abbreviations within a block (or a section within the abbreviations block), must
974 be enumerated in order, starting at index
<code>0</code>.
</p>
975 <p>Valid encodings
<code>Ei
</code>, and the corresponding sequence of (unsigned) integers
976 <code>EEi
</code>, ( for
<code>1 <= i
<= M
</code>) are defined by the following table:
</p>
977 <table border=
"1" class=
"docutils">
980 <thead valign=
"bottom">
981 <tr class=
"row-odd"><th class=
"head">Ei
</th>
982 <th class=
"head">EEi
</th>
983 <th class=
"head">Form
</th>
987 <tr class=
"row-even"><td>C
</td>
989 <td>Literal C in corresponding position in record.
</td>
991 <tr class=
"row-odd"><td>fixed(N)
</td>
993 <td>Encode value as a fixed sequence of N bits.
</td>
995 <tr class=
"row-even"><td>vbr(N)
</td>
997 <td>Encode value using a variable bit rate of N.
</td>
999 <tr class=
"row-odd"><td>char6
</td>
1001 <td>Encode value as
6-bit char containing
1002 characters [a-zA-Z0-
9._].
</td>
1004 <tr class=
"row-even"><td>array
</td>
1006 <td>Allow zero or more of the succeeding abbreviation.
</td>
1010 <p>Note that
‘array
’ can only appear as the second to last element in the
1011 abbreviation. Notationally,
<code>array(EM)
</code> is used in place of
<code>array
</code> and
1012 <code>EM
</code>, the last two entries in an abbreviation.
</p>
1013 <p><strong>Examples
</strong>:
</p>
1014 <pre class=
"prettyprint">
1015 0:
0|
<65532,
80,
69,
88,
69,
1,
0,|Magic Number: 'PEXE' (
80,
69,
88,
69)
1016 |
8,
0,
17,
0,
4,
0,
2,
0,
0, |PNaCl Version:
2
1018 16:
0|
1:
<65535,
8,
2> |module { // BlockID =
8
1019 24:
0|
3:
<1,
1> | version
1;
1020 26:
4|
1:
<65535,
0,
2> | abbreviations { // BlockID =
0
1021 36:
0|
1:
<1,
14> | valuesymtab:
1022 38:
4|
2:
<65533,
4,
0,
1,
3,
0,|
@a0 = abbrev
<fixed(
3), vbr(
8),
1023 |
2,
8,
0,
3,
0,
1,
8> | array(fixed(
8))
>;
1024 43:
2|
2:
<65533,
4,
1,
1,
0,
2,|
@a1 = abbrev
<1, vbr(
8),
1025 |
8,
0,
3,
0,
1,
7> | array(fixed(
7))
>;
1026 48:
0|
2:
<65533,
4,
1,
1,
0,
2,|
@a2 = abbrev
<1, vbr(
8),
1027 |
8,
0,
3,
0,
4> | array(char6)
>;
1028 52:
1|
2:
<65533,
4,
1,
2,
0,
2,|
@a3 = abbrev
<2, vbr(
8),
1029 |
8,
0,
3,
0,
4> | array(char6)
>;
1030 56:
2|
1:
<1,
11> | constants:
1031 58:
6|
2:
<65533,
2,
1,
1,
0,
1,|
@a0 = abbrev
<1, fixed(
2)
>;
1033 61:
7|
2:
<65533,
2,
1,
4,
0,
2,|
@a1 = abbrev
<4, vbr(
8)
>;
1035 65:
0|
2:
<65533,
2,
1,
4,
1,
0>|
@a2 = abbrev
<4,
0>;
1036 68:
1|
2:
<65533,
2,
1,
6,
0,
2,|
@a3 = abbrev
<6, vbr(
8)
>;
1038 71:
2|
1:
<1,
12> | function:
1039 73:
6|
2:
<65533,
4,
1,
20,
0, |
@a0 = abbrev
<20, vbr(
6), vbr(
4),
1040 |
2,
6,
0,
2,
4,
0,
2, | vbr(
4)
>;
1042 79:
1|
2:
<65533,
4,
1,
2,
0,
2,|
@a1 = abbrev
<2, vbr(
6), vbr(
6),
1043 |
6,
0,
2,
6,
0,
1,
4> | fixed(
4)
>;
1044 84:
4|
2:
<65533,
4,
1,
3,
0,
2,|
@a2 = abbrev
<3, vbr(
6),
1045 |
6,
0,
1,
2,
0,
1,
4> | fixed(
2), fixed(
4)
>;
1046 89:
7|
2:
<65533,
1,
1,
10> |
@a3 = abbrev
<10>;
1047 91:
7|
2:
<65533,
2,
1,
10,
0, |
@a4 = abbrev
<10, vbr(
6)
>;
1049 95:
0|
2:
<65533,
1,
1,
15> |
@a5 = abbrev
<15>;
1050 97:
0|
2:
<65533,
3,
1,
43,
0, |
@a6 = abbrev
<43, vbr(
6),
1051 |
2,
6,
0,
1,
2> | fixed(
2)
>;
1052 101:
2|
2:
<65533,
4,
1,
24,
0, |
@a7 = abbrev
<24, vbr(
6), vbr(
6),
1053 |
2,
6,
0,
2,
6,
0,
2, | vbr(
4)
>;
1055 106:
5|
1:
<1,
19> | globals:
1056 109:
1|
2:
<65533,
3,
1,
0,
0,
2,|
@a0 = abbrev
<0, vbr(
6),
1057 |
6,
0,
1,
1> | fixed(
1)
>;
1058 113:
3|
2:
<65533,
2,
1,
1,
0,
2,|
@a1 = abbrev
<1, vbr(
8)
>;
1060 116:
4|
2:
<65533,
2,
1,
2,
0,
2,|
@a2 = abbrev
<2, vbr(
8)
>;
1062 119:
5|
2:
<65533,
3,
1,
3,
0,
3,|
@a3 = abbrev
<3, array(fixed(
8))
>
1064 123:
2|
2:
<65533,
2,
1,
4,
0,
2,|
@a4 = abbrev
<4, vbr(
6)
>;
1066 126:
3|
2:
<65533,
3,
1,
4,
0,
2,|
@a5 = abbrev
<4, vbr(
6), vbr(
6)
>;
1068 130:
5|
0:
<65534> | }
1069 132:
0|
1:
<65535,
17,
3> | types { // BlockID =
17
1070 140:
0|
2:
<65533,
4,
1,
21,
0, | %a0 = abbrev
<21, fixed(
1),
1071 |
1,
1,
0,
3,
0,
1,
2> | array(fixed(
2))
>;
1072 144:
7|
3:
<1,
3> | count
3;
1073 147:
4|
3:
<7,
32> |
@t0 = i32;
1074 150:
7|
4:
<21,
0,
0,
0,
0> |
@t1 = i32 (i32, i32);
<%a0
>
1075 152:
7|
3:
<2> |
@t2 = void;
1076 154:
6|
0:
<65534> | }
1077 156:
0|
3:
<8,
1,
0,
0,
0> | define external i32
@f0(i32, i32);
1078 160:
6|
1:
<65535,
19,
4> | globals { // BlockID =
19
1079 168:
0|
3:
<5,
0> | count
0;
1080 170:
6|
0:
<65534> | }
1081 172:
0|
1:
<65535,
14,
3> | valuesymtab { // BlockID =
14
1082 180:
0|
6:
<1,
0,
102> |
@f0 :
"f
";
<@a2
>
1083 182:
7|
0:
<65534> | }
1084 184:
0|
1:
<65535,
12,
4> | function i32
@f0(i32 %p0, i32 %p1) {
1086 192:
0|
3:
<1,
1> | blocks
1;
1088 194:
6|
5:
<2,
2,
1,
0> | %v0 = add i32 %p0, %p1;
<@a1
>
1089 197:
2|
5:
<2,
3,
1,
0> | %v1 = add i32 %p0, %v0;
<@a1
>
1090 199:
6|
8:
<10,
1> | ret i32 %v1;
<@a4
>
1091 201:
0|
0:
<65534> | }
1092 204:
0|
0:
<65534> |}
1094 <p>Note that the example above shows the standard abbreviations used by
1095 <em>pnacl-finalize
</em>.
</p>
1096 <h2 id=
"types-block"><span id=
"link-for-types-block-section"></span>Types Block
</h2>
1097 <p>The types block defines all types used in a program. It must appear in the
1098 <a class=
"reference internal" href=
"#link-for-module-block"><em>module block
</em></a>, before any
<a class=
"reference internal" href=
"#link-for-function-address-section"><em>function
1099 address
</em></a> records, the
<a class=
"reference internal" href=
"#link-for-globals-block-section"><em>globals
1100 block
</em></a>, the
<a class=
"reference internal" href=
"#link-for-valuesymtab-block-section"><em>valuesymtab
1101 block
</em></a>, and any
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function
1102 blocks
</em></a>.
</p>
1103 <p>All types used in a program must be defined in the types block. Many PNaClAsm
1104 constructs allow one to use explicit type names, rather than the type
1105 identifiers defined by this block. However, they are internally converted to the
1106 corresponding type identifier in the types block. Hence, the requirement that
1107 the types block must appear early in the module block.
</p>
1108 <p>Each record in the types block defines a type used by the program. Types can be
1109 broken into the following groups:
</p>
1110 <dl class=
"docutils">
1111 <dt>Primitive value types
</dt>
1112 <dd>Defines the set of base types for values. This includes various sizes of
1113 integer and floating point types.
</dd>
1115 <dd>A primitive type that doesn
’t represent any value and has no size.
</dd>
1116 <dt>Function types
</dt>
1117 <dd>The type signatures of functions.
</dd>
1118 <dt>Vector type
</dt>
1119 <dd>Defines vectors of primitive types.
</dd>
1121 <p>In addition, any type that is not defined using another type is a primitive
1122 type. All other types (i.e. function and vector) are composite types.
</p>
1123 <p>Types must be defined in a topological order, causing primitive types to appear
1124 before the composite types that use them. Each type must be unique. There are no
1125 additional restrictions on the order that types can be defined in a types block.
</p>
1126 <p>The following subsections introduce each valid PNaClAsm type, and the
1127 corresponding PNaClAsm construct that defines the type. Types not defined in the
1128 types block, can
’t be used in a PNaCl program.
</p>
1129 <p>The first record of a types block must be a
<a class=
"reference internal" href=
"#link-for-types-count-record"><em>count
1130 record
</em></a>, defining how many types are defined by the
1131 types block. All remaining records defines a type. The following subsections
1132 defines valid records within a types block. The order of type records is
1133 important. The position of each defining record implicitly defines the type ID
1134 that will be used to denote that type, within other PNaCl records of the bitcode
1136 <p>To make this more concrete, consider the following example types block:
</p>
1137 <pre class=
"prettyprint">
1138 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
1139 48:
0|
3:
<1,
4> | count
4;
1140 50:
4|
3:
<7,
32> |
@t0 = i32;
1141 53:
6|
3:
<3> |
@t1 = float;
1142 55:
4|
3:
<2> |
@t2 = void;
1143 57:
2|
3:
<21,
0,
2,
0,
1> |
@t3 = void (i32, float);
1144 62:
0|
0:
<65534> | }
1146 <p>This example defines a types block that defines four type IDs:
</p>
1147 <dl class=
"docutils">
1149 <dd>A
32-bit integer type.
</dd>
1151 <dd>A
32-bit floating point type.
</dd>
1153 <dd>The void type.
</dd>
1155 <dd>A function, taking
32-bit integer and float point arguments that returns
1158 <h3 id=
"count-record"><span id=
"link-for-types-count-record"></span>Count Record
</h3>
1159 <p>The
<em>count record
</em> defines how many types are defined in the types
1160 block. Following the types count record are records that define types used by
1161 the PNaCl program.
</p>
1162 <p><strong>Syntax
</strong>:
</p>
1163 <pre class=
"prettyprint">
1166 <p><strong>Record
</strong>:
</p>
1167 <pre class=
"prettyprint">
1170 <p><strong>Semantics
</strong>:
</p>
1171 <p>This construct defines the number of types used by the PNaCl program.
<code>N
</code> is
1172 the number of types defined in the types block. It is an error to define more
1173 (or fewer) types than value
<code>N
</code>, within the enclosing types block.
</p>
1174 <p><strong>Constraints
</strong>:
</p>
1175 <pre class=
"prettyprint">
1176 AA == AbbrevIndex(A)
&
1179 <p><strong>Updates
</strong>:
</p>
1180 <pre class=
"prettyprint">
1183 <p><strong>Examples
</strong>:
</p>
1184 <pre class=
"prettyprint">
1185 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
1186 48:
0|
3:
<1,
4> | count
4;
1187 50:
4|
3:
<7,
32> |
@t0 = i32;
1188 53:
6|
3:
<3> |
@t1 = float;
1189 55:
4|
3:
<2> |
@t2 = void;
1190 57:
2|
3:
<21,
0,
2,
0,
1> |
@t3 = void (i32, float);
1191 62:
0|
0:
<65534> | }
1193 <h3 id=
"void-type">Void Type
</h3>
1194 <p>The
<em>void
</em> type record defines the void type, which corresponds to the type that
1195 doesn
’t define any value, and has no size.
</p>
1196 <p><strong>Syntax
</strong>:
</p>
1197 <pre class=
"prettyprint">
1198 @tN = void;
<A
>
1200 <p><strong>Record
</strong>:
</p>
1201 <pre class=
"prettyprint">
1204 <p><strong>Semantics
</strong>:
</p>
1205 <p>The void type record defines the type that has no values and has no size.
</p>
1206 <p><strong>Constraints
</strong>:
</p>
1207 <pre class=
"prettyprint">
1208 AA == AbbrevIndex(A)
&
1211 <p><strong>Updates
</strong>:
</p>
1212 <pre class=
"prettyprint">
1214 TypeOf(
@tN) = void;
1216 <p><strong>Examples
</strong>:
</p>
1217 <pre class=
"prettyprint">
1218 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
1219 48:
0|
3:
<1,
4> | count
4;
1220 50:
4|
3:
<7,
32> |
@t0 = i32;
1221 53:
6|
3:
<3> |
@t1 = float;
1222 55:
4|
3:
<2> |
@t2 = void;
1223 62:
0|
0:
<65534> | }
1225 <h3 id=
"integer-types">Integer Types
</h3>
1226 <p>PNaClAsm allows integer types for various bit sizes. Valid bit sizes are
1,
8,
1227 16,
32, and
64. Integers can be signed or unsigned, but the signed component of
1228 an integer is not specified by the type. Rather, individual instructions
1229 determine whether the value is assumed to be signed or unsigned.
</p>
1230 <p>It should be noted that in PNaClAsm, all pointers are implemented as
32-bit
1231 (unsigned) integers. There isn
’t a separate type for pointers. The only way to
1232 tell that a
32-bit integer is a pointer, is when it is used in an instruction
1233 that requires a pointer (such as load and store instructions).
</p>
1234 <p><strong>Syntax
</strong>:
</p>
1235 <pre class=
"prettyprint">
1236 @tN = iB;
<A
>
1238 <p><strong>Record
</strong>:
</p>
1239 <pre class=
"prettyprint">
1242 <p><strong>Semantics
</strong>:
</p>
1243 <p>An integer type record defines an integer type.
<code>B
</code> defines the number of bits
1244 of the integer type.
</p>
1245 <p><strong>Constraints
</strong>:
</p>
1246 <pre class=
"prettyprint">
1247 AA == AbbrevIndex(A)
&
1249 B in {
1,
8,
16,
32,
64}
1251 <p><strong>Updates
</strong>:
</p>
1252 <pre class=
"prettyprint">
1254 TypeOf(
@tN) = iB;
1256 <p><strong>Examples
</strong>:
</p>
1257 <pre class=
"prettyprint">
1258 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
1259 48:
0|
3:
<1,
7> | count
7;
1260 50:
4|
3:
<7,
64> |
@t0 = i64;
1261 53:
6|
3:
<7,
1> |
@t1 = i1;
1262 56:
2|
3:
<7,
8> |
@t2 = i8;
1263 58:
6|
3:
<7,
16> |
@t3 = i16;
1264 61:
2|
3:
<7,
32> |
@t4 = i32;
1265 64:
4|
3:
<21,
0,
0,
1> |
@t5 = i64 (i1);
1266 68:
4|
3:
<2> |
@t6 = void;
1267 70:
2|
0:
<65534> | }
1269 <h3 id=
"bit-floating-point-type">32-Bit Floating Point Type
</h3>
1270 <p>PNaClAsm allows computation on
32-bit floating point values. A floating point
1271 type record defines the
32-bit floating point type.
</p>
1272 <p><strong>Syntax
</strong>:
</p>
1273 <pre class=
"prettyprint">
1274 @tN = float;
<A
>
1276 <p><strong>Record
</strong>:
</p>
1277 <pre class=
"prettyprint">
1280 <p><strong>Semantics
</strong>:
</p>
1281 <p>A floating point type record defines the
32-bit floating point type.
</p>
1282 <p><strong>Constraints
</strong>:
</p>
1283 <pre class=
"prettyprint">
1284 AA == AbbrevIndex(A)
&
1287 <p><strong>Updates
</strong>:
</p>
1288 <pre class=
"prettyprint">
1290 TypeOf(
@tN) = float;
1292 <p><strong>Examples
</strong>:
</p>
1293 <pre class=
"prettyprint">
1294 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
1295 48:
0|
3:
<1,
4> | count
4;
1296 50:
4|
3:
<4> |
@t0 = double;
1297 52:
2|
3:
<3> |
@t1 = float;
1298 54:
0|
3:
<21,
0,
0,
1> |
@t2 = double (float);
1299 58:
0|
3:
<2> |
@t3 = void;
1300 59:
6|
0:
<65534> | }
1302 <h3 id=
"id1">64-bit Floating Point Type
</h3>
1303 <p>PNaClAsm allows computation on
64-bit floating point values. A
64-bit floating
1304 type record defines the
64-bit floating point type.
</p>
1305 <p><strong>Syntax
</strong>:
</p>
1306 <pre class=
"prettyprint">
1307 @tN = double;
<A
>
1309 <p><strong>Record
</strong>:
</p>
1310 <pre class=
"prettyprint">
1313 <p><strong>Semantics
</strong>:
</p>
1314 <p>A double type record defines the
64-bit floating point type.
</p>
1315 <p><strong>Constraints
</strong>:
</p>
1316 <pre class=
"prettyprint">
1317 AA == AbbrevIndex(A)
&
1320 <p><strong>Updates
</strong>:
</p>
1321 <pre class=
"prettyprint">
1323 TypeOf(
@tN) = double;
1325 <p><strong>Examples
</strong>:
</p>
1326 <pre class=
"prettyprint">
1327 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
1328 48:
0|
3:
<1,
4> | count
4;
1329 50:
4|
3:
<4> |
@t0 = double;
1330 52:
2|
3:
<3> |
@t1 = float;
1331 54:
0|
3:
<21,
0,
0,
1> |
@t2 = double (float);
1332 58:
0|
3:
<2> |
@t3 = void;
1333 59:
6|
0:
<65534> | }
1335 <h3 id=
"vector-types">Vector Types
</h3>
1336 <p>A vector type is a derived type that represents a vector of elements. Vector
1337 types are used when multiple primitive data values are operated in parallel
1338 using a single (SIMD)
<a class=
"reference internal" href=
"#link-for-vector-instructions"><em>vector instruction
</em></a>. A
1339 vector type requires a size (number of elements) and an underlying primitive
1341 <p><strong>Syntax
</strong>:
</p>
1342 <pre class=
"prettyprint">
1343 @tN =
< E x T
> <A
>
1345 <p><strong>Record
</strong>:
</p>
1346 <pre class=
"prettyprint">
1347 AA:
<12, E, TT
>
1349 <p><strong>Semantics
</strong>:
</p>
1350 <p>The vector type defines a vector of elements.
<code>T
</code> is the type of each
1351 element.
<code>E
</code> is the number of elements in the vector.
</p>
1352 <p>Vector types can only be defined on
<code>i1
</code>,
<code>i8
</code>,
<code>i16
</code>,
<code>i32
</code>, and
1353 <code>float
</code>. All vector types, except those on
<code>i1
</code>, must contain exactly
128
1354 bits. The valid element sizes are restricted as follows:
</p>
1355 <table border=
"1" class=
"docutils">
1358 <thead valign=
"bottom">
1359 <tr class=
"row-odd"><th class=
"head">Type
</th>
1360 <th class=
"head">Valid element sizes
</th>
1363 <tbody valign=
"top">
1364 <tr class=
"row-even"><td>i1
</td>
1367 <tr class=
"row-odd"><td>i8
</td>
1370 <tr class=
"row-even"><td>i16
</td>
1373 <tr class=
"row-odd"><td>i32
</td>
1376 <tr class=
"row-even"><td>float
</td>
1381 <p><strong>Constraints
</strong>:
</p>
1382 <pre class=
"prettyprint">
1383 AA == AbbrevIndex(A)
&
1384 TT == AbsoluteIndex(TypeID(T))
&
1387 <p><strong>Updates
</strong>:
</p>
1388 <pre class=
"prettyprint">
1390 TypeOf(
@tN) =
<E x T
>
1392 <p><strong>Examples
</strong>:
</p>
1393 <pre class=
"prettyprint">
1394 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
1395 48:
0|
3:
<1,
14> | count
14;
1396 50:
4|
3:
<7,
32> |
@t0 = i32;
1397 53:
6|
3:
<7,
1> |
@t1 = i1;
1398 56:
2|
3:
<2> |
@t2 = void;
1399 58:
0|
3:
<12,
4,
1> |
@t3 =
<4 x i1
>;
1400 61:
2|
3:
<12,
8,
1> |
@t4 =
<8 x i1
>;
1401 64:
4|
3:
<12,
16,
1> |
@t5 =
<16 x i1
>;
1402 67:
6|
3:
<7,
8> |
@t6 = i8;
1403 70:
2|
3:
<12,
16,
6> |
@t7 =
<16 x i8
>;
1404 73:
4|
3:
<7,
16> |
@t8 = i16;
1405 76:
0|
3:
<12,
8,
8> |
@t9 =
<8 x i16
>;
1406 79:
2|
3:
<12,
4,
0> |
@t10 =
<4 x i32
>;
1407 82:
4|
3:
<3> |
@t11 = float;
1408 84:
2|
3:
<12,
4,
11> |
@t12 =
<4 x float
>;
1409 87:
4|
3:
<21,
0,
2> |
@t13 = void ();
1410 90:
6|
0:
<65534> | }
1412 <h3 id=
"function-type"><span id=
"link-for-function-type"></span>Function Type
</h3>
1413 <p>The
<em>function
</em> type can be thought of as a function signature. It consists of a
1414 return type, and a (possibly empty) list of formal parameter types.
</p>
1415 <p><strong>Syntax
</strong>:
</p>
1416 <pre class=
"prettyprint">
1417 %tN = RT (T1, ... , TM)
<A
>
1419 <p><strong>Record
</strong>:
</p>
1420 <pre class=
"prettyprint">
1421 AA:
<21,
0, IRT, IT1, ... , ITM
>
1423 <p><strong>Semantics
</strong>:
</p>
1424 <p>The function type defines the signature of a function.
<code>RT
</code> is the return type
1425 of the function, while types
<code>T1
</code> through
<code>TM
</code> are the types of the
1426 arguments. Indices to the corresponding type identifiers are stored in the
1427 corresponding record.
</p>
1428 <p>The return value must either be a primitive type, type
<code>void
</code>, or a vector
1429 type. Parameter types can be a primitive or vector type.
</p>
1430 <p>For ordinary functions, the only valid integer types that can be used for a
1431 return or parameter type are
<code>i32
</code> and
<code>i64
</code>. All other integer types are
1433 <p>For
<a class=
"reference internal" href=
"#link-for-intrinsic-functions-section"><em>intrinsic functions
</em></a>, all
1434 integer types are allowed for both return and parameter types.
</p>
1435 <p><strong>Constraints
</strong>:
</p>
1436 <pre class=
"prettyprint">
1437 AA == AbbrevIndex(A)
&
1439 IRT == AbsoluteIndex(TypeID(RT))
&
1440 IT1 == AbsoluteIndex(TypeID(T1))
&
1442 ITM == AbsoluteIndex(TypeID(TM))
&
1445 <p><strong>Updates
</strong>:
</p>
1446 <pre class=
"prettyprint">
1448 TypeOf(
@tN) = RT (T1, ... , TM)
1450 <p><strong>Examples
</strong>:
</p>
1451 <pre class=
"prettyprint">
1452 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
1453 48:
0|
3:
<1,
7> | count
7;
1454 50:
4|
3:
<7,
32> |
@t0 = i32;
1455 53:
6|
3:
<3> |
@t1 = float;
1456 55:
4|
3:
<4> |
@t2 = double;
1457 57:
2|
3:
<21,
0,
2,
1> |
@t3 = double (float);
1458 61:
2|
3:
<2> |
@t4 = void;
1459 63:
0|
3:
<21,
0,
4> |
@t5 = void ();
1460 66:
2|
3:
<21,
0,
0,
0,
1,
0,
2>|
@t6 =
1461 | | i32 (i32, float, i32, double);
1462 72:
4|
0:
<65534> | }
1464 <h2 id=
"globals-block"><span id=
"link-for-globals-block-section"></span>Globals Block
</h2>
1465 <p>The globals block defines global addresses of variables and constants, used by
1466 the PNaCl program. It also defines the memory associated with the global
1467 addresses, and how to initialize each global variable/constant. It must appear
1468 in the
<a class=
"reference internal" href=
"#link-for-module-block"><em>module block
</em></a>. It must appear after the
1469 <a class=
"reference internal" href=
"#link-for-types-block-section"><em>types block
</em></a>, as well as after all
1470 <a class=
"reference internal" href=
"#link-for-function-address-section"><em>function address
</em></a> records. But, it must
1471 also appear before the
<a class=
"reference internal" href=
"#link-for-valuesymtab-block-section"><em>valuesymtab
1472 block
</em></a>, and any
1473 <a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function blocks
</em></a>.
</p>
1474 <p>The globals block begins with a
<a class=
"reference internal" href=
"#link-for-globals-count-record"><em>count
1475 record
</em></a>, defining how many global addresses are
1476 defined by the PNaCl program. It is then followed by a sequence of records that
1477 defines each global address, and how each global address is initialized.
</p>
1478 <p>The standard sequence, for defining global addresses, begins with a global
1479 address record. It is then followed by a sequence of records defining how the
1480 global address is initialized. If the initializer is simple, a single record is
1481 used. Otherwise, the initializer is preceded with a
<a class=
"reference internal" href=
"#link-for-compound-initializer"><em>compound
1482 record
</em></a>, specifying a number
<em>N
</em>, followed by
1483 sequence of
<em>N
</em> simple initializer records.
</p>
1484 <p>The size of the memory referenced by each global address is defined by its
1485 initializer records. All simple initializer records define a sequence of
1486 bytes. A compound initializer defines the sequence of bytes by concatenating the
1487 corresponding sequence of bytes for each of its simple initializer records.
</p>
1488 <p>For notational convenience, PNaClAsm begins a compound record with a
“{
”, and
1489 inserts a
“}
” after the last initializer record associated with the compound
1490 record. This latter
“}
” does not correspond to any record. It is implicitly
1491 assumed by the size specified in the compound record, and is added only to
1492 improve readability.
</p>
1493 <p>Explicit alignment is specified for global addresses, and must be a power of
1494 2. See
<a class=
"reference internal" href=
"#link-for-memory-blocks-and-alignment-section"><em>memory blocks and
1495 alignment
</em></a> for a more detailed
1496 discussion on how to define alignment.
</p>
1497 <p>For example, consider the following pnacl-bcdis output snippet:
</p>
1498 <pre class=
"prettyprint">
1499 52:
0|
1:
<65535,
19,
2> | globals { // BlockID =
19
1500 60:
0|
3:
<5,
2> | count
2;
1501 62:
4|
3:
<0,
1,
1> | const
@g0, align
1,
1502 65:
6|
3:
<2,
8> | zerofill
8;
1503 68:
2|
3:
<0,
1,
0> | var
@g1, align
1,
1504 71:
4|
3:
<1,
2> | initializers
2 {
1505 74:
0|
3:
<3,
1,
2,
3,
4> | {
1,
2,
3,
4}
1506 78:
6|
3:
<2,
2> | zerofill
2;
1508 81:
2|
0:
<65534> | }
1510 <p>This snippet defines the global constant
<code>@g0
</code>, and the global variable
1511 <code>@g1
</code>.
<code>@g0
</code> is
8 bytes long, and initialized to zero.
<code>@g1
</code> is
1512 initialized with
6 bytes:
<code>1 2 3 4 0 0</code>.
</p>
1513 <h3 id=
"link-for-globals-count-record"><span id=
"id2"></span>Count Record
</h3>
1514 <p>The count record defines the number of global addresses used by the PNaCl
1516 <p><strong>Syntax
</strong>:
</p>
1517 <pre class=
"prettyprint">
1520 <p><strong>Record
</strong>:
</p>
1521 <pre class=
"prettyprint">
1524 <p><strong>Semantics
</strong>:
</p>
1525 <p>This record must appear first in the globals block. The count record defines
1526 the number of global addresses used by the program.
</p>
1527 <p><strong>Constraints
</strong>:
</p>
1528 <pre class=
"prettyprint">
1529 AA == AbbrevIndex(A)
1531 <p><strong>Updates
</strong>:
</p>
1532 <pre class=
"prettyprint">
1533 ExpectedGlobals = N;
1534 ExpectedInitializers =
0;
1536 <p><strong>Examples
</strong>:
</p>
1537 <pre class=
"prettyprint">
1538 52:
0|
1:
<65535,
19,
2> | globals { // BlockID =
19
1539 60:
0|
3:
<5,
2> | count
2;
1540 62:
4|
3:
<0,
1,
1> | const
@g0, align
1,
1541 65:
6|
3:
<2,
8> | zerofill
8;
1542 68:
2|
3:
<0,
1,
0> | var
@g1, align
1,
1543 71:
4|
3:
<1,
2> | initializers
2 {
1544 74:
0|
3:
<3,
1,
2,
3,
4> | {
1,
2,
3,
4}
1545 78:
6|
3:
<2,
2> | zerofill
2;
1547 81:
2|
0:
<65534> | }
1549 <h3 id=
"global-variable-addresses"><span id=
"link-for-global-variable-address"></span>Global Variable Addresses
</h3>
1550 <p>A global variable address record defines a global address to global data. The
1551 global variable address record must be immediately followed by initializer
1552 record(s) that define how the corresponding global variable is initialized.
</p>
1553 <p><strong>Syntax
</strong>:
</p>
1554 <pre class=
"prettyprint">
1555 var
@gN, align V,
<A
>
1557 <p><strong>Record
</strong>:
</p>
1558 <pre class=
"prettyprint">
1559 AA:
<0, VV,
0>
1561 <p><strong>Semantics
</strong>:
</p>
1562 <p>A global variable address record defines a global address for a global variable.
1563 <code>V
</code> is the
<a class=
"reference internal" href=
"#link-for-memory-blocks-and-alignment-section"><em>memory
1564 alignment
</em></a> for the global variable
1565 address, and is a power of
2.
</p>
1566 <p>It is assumed that the memory, referenced by the global variable address, can be
1567 both read and written to.
</p>
1568 <p><strong>Constraints
</strong>:
</p>
1569 <pre class=
"prettyprint">
1570 AA == AbbrevIndex(A)
&
1571 N == NumGlobalAddresses
&
1572 ExpectedInitializers ==
0 &
1575 <p><strong>Updates
</strong>:
</p>
1576 <pre class=
"prettyprint">
1577 ++NumGlobalAddresses;
1578 ExpectedInitializers =
1;
1579 TypeOf(
@gN) = i32;
1581 <p><strong>Examples
</strong>:
</p>
1582 <pre class=
"prettyprint">
1583 52:
0|
1:
<65535,
19,
2> | globals { // BlockID =
19
1584 60:
0|
3:
<5,
2> | count
2;
1585 62:
4|
3:
<0,
3,
0> | var
@g0, align
4,
1586 65:
6|
3:
<2,
8> | zerofill
8;
1587 68:
2|
3:
<0,
1,
0> | var
@g1, align
1,
1588 71:
4|
3:
<3,
1,
2,
3,
4> | {
1,
2,
3,
4}
1589 76:
2|
0:
<65534> | }
1590 80:
0|
0:
<65534> |}
1592 <h3 id=
"global-constant-addresses"><span id=
"link-for-global-constant-address"></span>Global Constant Addresses
</h3>
1593 <p>A global constant address record defines an address corresponding to a global
1594 constant that can
’t be modified by the program. The global constant address
1595 record must be immediately followed by initializer record(s) that define how
1596 the corresponding global constant is initialized.
</p>
1597 <p><strong>Syntax
</strong>:
</p>
1598 <pre class=
"prettyprint">
1599 const
@gN, align V,
<A
>
1601 <p><strong>Record
</strong>:
</p>
1602 <pre class=
"prettyprint">
1603 AA:
<0, VV,
1>
1605 <p><strong>Semantics
</strong>:
</p>
1606 <p>A global constant address record defines a global address for a global constant.
1607 <code>V
</code> is the
<a class=
"reference internal" href=
"#link-for-memory-blocks-and-alignment-section"><em>memory
1608 alignment
</em></a> for the global constant
1609 address, and is a power of
2.
</p>
1610 <p>It is assumed that the memory, referenced by the global constant address, is
1611 only read, and can
’t be written to.
</p>
1612 <p>Note that the only difference between a global variable address and a global
1613 constant address record is the third element of the record. If the value is
1614 zero, it defines a global variable address. If the value is one, it defines a
1615 global constant address.
</p>
1616 <p><strong>Constraints
</strong>:
</p>
1617 <pre class=
"prettyprint">
1618 AA == AbbrevIndex(A)
&
1619 N == NumGlobalAddresses
&
1620 ExpectedInitializers ==
0 &
1623 <p><strong>Updates
</strong>:
</p>
1624 <pre class=
"prettyprint">
1625 ++NumGlobalAddresses;
1626 ExpectedInitializers =
1;
1627 TypeOf(
@gN) = i32;
1629 <p><strong>Examples
</strong>:
</p>
1630 <pre class=
"prettyprint">
1631 52:
0|
1:
<65535,
19,
2> | globals { // BlockID =
19
1632 60:
0|
3:
<5,
2> | count
2;
1633 62:
4|
3:
<0,
3,
1> | const
@g0, align
4,
1634 65:
6|
3:
<2,
8> | zerofill
8;
1635 68:
2|
3:
<0,
1,
1> | const
@g1, align
1,
1636 71:
4|
3:
<3,
1,
2,
3,
4> | {
1,
2,
3,
4}
1637 76:
2|
0:
<65534> | }
1639 <h3 id=
"zerofill-initializer">Zerofill Initializer
</h3>
1640 <p>The zerofill initializer record initializes a sequence of bytes, associated with
1641 a global address, with zeros.
</p>
1642 <p><strong>Syntax
</strong>:
</p>
1643 <pre class=
"prettyprint">
1644 zerofill N;
<A
>
1646 <p><strong>Record
</strong>:
</p>
1647 <pre class=
"prettyprint">
1650 <p><strong>Semantics
</strong>:
</p>
1651 <p>A zerofill initializer record initializes a sequence of bytes, associated with a
1652 global address, with zeros. The number of bytes initialized to zero is
<code>N
</code>.
</p>
1653 <p><strong>Constraints
</strong>:
</p>
1654 <pre class=
"prettyprint">
1655 AA == AbbrevIndex(A)
&
1656 ExpectedInitializers
> 0
1658 <p><strong>Updates
</strong>:
</p>
1659 <pre class=
"prettyprint">
1660 --ExpectedInitializers;
1662 <p><strong>Examples
</strong>:
</p>
1663 <pre class=
"prettyprint">
1664 52:
0|
1:
<65535,
19,
2> | globals { // BlockID =
19
1665 60:
0|
3:
<5,
2> | count
2;
1666 62:
4|
3:
<0,
3,
1> | const
@g0, align
4,
1667 65:
6|
3:
<2,
8> | zerofill
8;
1668 68:
2|
3:
<0,
1,
0> | var
@g1, align
1,
1669 71:
4|
3:
<2,
4> | zerofill
4;
1670 74:
0|
0:
<65534> | }
1672 <h3 id=
"data-initializer">Data Initializer
</h3>
1673 <p>Data records define a sequence of bytes. These bytes define the initial value of
1674 the contents of the corresponding memory.
</p>
1675 <p><strong>Syntax
</strong>:
</p>
1676 <pre class=
"prettyprint">
1677 { B1 , .... , BN }
<A
>
1679 <p><strong>Record
</strong>:
</p>
1680 <pre class=
"prettyprint">
1681 AA:
<3, B1, ..., BN
>
1683 <p><strong>Semantics
</strong>:
</p>
1684 <p>A data record defines a sequence of (unsigned) bytes
<code>B1
</code> through
<code>BN
</code>, that
1685 initialize
<code>N
</code> bytes of memory.
</p>
1686 <p><strong>Constraints
</strong>:
</p>
1687 <pre class=
"prettyprint">
1688 AA == AbbrevIndex(A)
&
1689 ExpectedInitializers
> 0
1691 <p><strong>Updates
</strong>:
</p>
1692 <pre class=
"prettyprint">
1693 --ExpectedInitializers;
1695 <p><strong>Examples
</strong>:
</p>
1696 <pre class=
"prettyprint">
1697 56:
0|
3:
<8,
1,
0,
1,
0> | declare external void
@f0();
1698 60:
6|
1:
<65535,
19,
2> | globals { // BlockID =
19
1699 68:
0|
3:
<5,
2> | count
2;
1700 70:
4|
3:
<0,
1,
1> | const
@g0, align
1,
1701 73:
6|
3:
<3,
1,
2,
97,
36,
44, | {
1,
2,
97,
36,
44,
88,
1702 |
88,
44,
50> |
44,
50}
1703 86:
0|
3:
<0,
1,
1> | const
@g1, align
1,
1704 89:
2|
3:
<1,
3> | initializers
3 {
1705 91:
6|
3:
<3,
1,
2,
3,
4> | {
1,
2,
3,
4}
1706 96:
4|
3:
<4,
0> | reloc
@f0;
1707 99:
0|
3:
<3,
99,
66,
22,
12> | {
99,
66,
22,
12}
1709 105:
2|
0:
<65534> | }
1711 <h3 id=
"relocation-initializer">Relocation Initializer
</h3>
1712 <p>A relocation initializer record allows one to define the initial value of a
1713 global address with the value of another global address (i.e. either
1714 <a class=
"reference internal" href=
"#link-for-function-address-section"><em>function
</em></a>,
1715 <a class=
"reference internal" href=
"#link-for-global-variable-address"><em>variable
</em></a>, or
1716 <a class=
"reference internal" href=
"#link-for-global-constant-address"><em>constant
</em></a>). Since addresses are
1717 pointers, a relocation initializer record defines
4 bytes of memory.
</p>
1718 <p><strong>Syntax
</strong>:
</p>
1719 <pre class=
"prettyprint">
1722 <p><strong>Record
</strong>:
</p>
1723 <pre class=
"prettyprint">
1726 <p><strong>Semantics
</strong>:
</p>
1727 <p>A relocation initializer record defines a
4-byte value containing the specified
1728 global address
<code>V
</code>.
</p>
1729 <p><strong>Constraints
</strong>:
</p>
1730 <pre class=
"prettyprint">
1731 AA == AbbrevIndex(A)
&
1732 VV == AbsoluteIndex(V)
&
1733 VV
>= NumFuncAddresses
&
1734 VV
< NumFuncAddresses + ExpectedGlobals
&
1735 ExpectedInitializers
> 0
1737 <p><strong>Updates
</strong>:
</p>
1738 <pre class=
"prettyprint">
1739 --ExpectedInitializers;
1741 <p><strong>Examples
</strong>:
</p>
1742 <pre class=
"prettyprint">
1743 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
1744 48:
0|
3:
<1,
2> | count
2;
1745 50:
4|
3:
<2> |
@t0 = void;
1746 52:
2|
3:
<21,
0,
0> |
@t1 = void ();
1747 55:
4|
0:
<65534> | }
1748 56:
0|
3:
<8,
1,
0,
1,
0> | declare external void
@f0();
1749 60:
6|
1:
<65535,
19,
2> | globals { // BlockID =
19
1750 68:
0|
3:
<5,
2> | count
2;
1751 70:
4|
3:
<0,
1,
0> | var
@g0, align
1,
1752 73:
6|
3:
<1,
3> | initializers
3 {
1753 76:
2|
3:
<4,
0> | reloc
@f0;
1754 78:
6|
3:
<4,
1> | reloc
@g0;
1755 81:
2|
3:
<4,
2> | reloc
@g1;
1757 83:
6|
3:
<0,
3,
0> | var
@g1, align
4,
1758 87:
0|
3:
<2,
4> | zerofill
4;
1759 89:
4|
0:
<65534> | }
1761 <p>This example defines global address
<code>@g0
</code> and
<code>@g1
</code>.
<code>@g0
</code> defines
12
1762 bytes of memory, and is initialized with three addresses
<code>@f1
</code>,
<code>@g0
</code>, and
1763 <code>@g1
</code>. Note that all global addresses can be used in a relocation
1764 initialization record, even if it isn
’t defined yet.
</p>
1765 <h3 id=
"subfield-relocation-initializer">Subfield Relocation Initializer
</h3>
1766 <p>A subfield relocation initializer record allows one to define the initial value
1767 of a global address with the value of another (non-function) global address
1768 (i.e. either
<a class=
"reference internal" href=
"#link-for-global-variable-address"><em>variable
</em></a> or
1769 <a class=
"reference internal" href=
"#link-for-global-constant-address"><em>constant
</em></a> address), plus a
1770 constant. Since addresses are pointers, a relocation initializer record defines
1771 4 bytes of memory.
</p>
1772 <p><strong>Syntax
</strong>:
</p>
1773 <pre class=
"prettyprint">
1774 reloc V + X;
<A
>
1775 reloc V - X;
<A
>
1777 <p><strong>Record
</strong>:
</p>
1778 <pre class=
"prettyprint">
1779 AA:
<4, VV, XXX
>
1781 <p><strong>Semantics
</strong>:
</p>
1782 <p>A subfield relocation initializer record defines a
4-byte value containing the
1783 specified global (non-function) address
<code>V
</code>, modified by the unsigned offset
1784 <code>X
</code>.
<code>XX
</code> is the corresponding signed offset. In the first form,
<code>XX ==
1785 X
</code>. In the second form,
<code>XX == -X
</code>.
</p>
1786 <p><strong>Constraints
</strong>:
</p>
1787 <pre class=
"prettyprint">
1788 AA == AbbrevIndex(A)
1789 VV == AbsoluteIndex(V)
1790 VV
>= NumFuncAddresses
1791 VV
< NumFuncAddresses + ExpectedGlobals
1792 ExpectedInitializers
> 0
1793 XXX == SignRotate(XX)
1795 <p><strong>Updates
</strong>:
</p>
1796 <pre class=
"prettyprint">
1797 --ExpectedInitializers;
1799 <p><strong>Examples
</strong>:
</p>
1800 <pre class=
"prettyprint">
1801 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
1802 48:
0|
3:
<1,
0> | count
0;
1803 50:
4|
0:
<65534> | }
1804 52:
0|
1:
<65535,
19,
2> | globals { // BlockID =
19
1805 60:
0|
3:
<5,
3> | count
3;
1806 62:
4|
3:
<0,
1,
0> | var
@g0, align
1,
1807 65:
6|
3:
<1,
3> | initializers
3 {
1808 68:
2|
3:
<4,
0,
1> | reloc
@g0 +
1;
1809 71:
4|
3:
<4,
1,
4294967295> | reloc
@g1 -
1;
1810 79:
2|
3:
<4,
2,
4> | reloc
@g2 +
4;
1812 82:
4|
3:
<0,
3,
0> | var
@g1, align
4,
1813 85:
6|
3:
<2,
4> | zerofill
4;
1814 88:
2|
3:
<0,
3,
0> | var
@g2, align
4,
1815 91:
4|
3:
<2,
8> | zerofill
8;
1816 94:
0|
0:
<65534> | }
1818 <h3 id=
"compound-initializer"><span id=
"link-for-compound-initializer"></span>Compound Initializer
</h3>
1819 <p>The compound initializer record must immediately follow a global
1820 <a class=
"reference internal" href=
"#link-for-global-variable-address"><em>variable
</em></a> or
1821 <a class=
"reference internal" href=
"#link-for-global-constant-address"><em>constant
</em></a> address record. It defines how
1822 many simple initializer records are used to define the initializer. The size of
1823 the corresponding memory is the sum of the bytes needed for each of the
1824 succeeding initializers.
</p>
1825 <p>Note that a compound initializer can
’t be used as a simple initializer of
1826 another compound initializer (i.e. nested compound initializers are not
1828 <p><strong>Syntax
</strong>:
</p>
1829 <pre class=
"prettyprint">
1830 initializers N {
<A
>
1834 <p><strong>Record
</strong>:
</p>
1835 <pre class=
"prettyprint">
1838 <p><strong>Semantics
</strong>:
</p>
1839 <p>Defines that the next
<cite>N
</cite> initializers should be associated with the global
1840 address of the previous record.
</p>
1841 <p><strong>Constraints
</strong>:
</p>
1842 <pre class=
"prettyprint">
1843 AA == AbbrevIndex(A)
&
1844 ExpectedInitializers ==
1
1846 <p><strong>Updates
</strong>:
</p>
1847 <pre class=
"prettyprint">
1848 ExpectedInitializers = N;
1850 <p><strong>Examples
</strong>:
</p>
1851 <pre class=
"prettyprint">
1852 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
1853 48:
0|
3:
<1,
0> | count
0;
1854 50:
4|
0:
<65534> | }
1855 52:
0|
1:
<65535,
19,
2> | globals { // BlockID =
19
1856 60:
0|
3:
<5,
2> | count
2;
1857 62:
4|
3:
<0,
0,
1> | const
@g0, align
0,
1858 65:
6|
3:
<1,
2> | initializers
2 {
1859 68:
2|
3:
<2,
8> | zerofill
8;
1860 70:
6|
3:
<3,
3,
2,
1,
0> | {
3,
2,
1,
0}
1862 75:
4|
3:
<0,
0,
0> | var
@g1, align
0,
1863 78:
6|
3:
<1,
2> | initializers
2 {
1864 81:
2|
3:
<3,
1,
2,
3,
4> | {
1,
2,
3,
4}
1865 86:
0|
3:
<2,
2> | zerofill
2;
1867 88:
4|
0:
<65534> | }
1869 <h2 id=
"valuesymtab-block"><span id=
"link-for-valuesymtab-block-section"></span>Valuesymtab Block
</h2>
1870 <p>The valuesymtab block does not define any values. Its only goal is to associate
1871 text names with external
<a class=
"reference internal" href=
"#link-for-function-address-section"><em>function
1872 addresses
</em></a>. Each association is defined by a
1873 record in the valuesymtab block. Currently, only
1874 <a class=
"reference internal" href=
"#link-for-intrinsic-functions-section"><em>intrinsic
</em></a> function addresses and
1875 the (external) start function (
<code>_start
</code>) can be named. All named function
1876 addresses must be external. Each record in the valuesymtab block is a
<em>entry
</em>
1877 record, defining a single name association.
</p>
1878 <h3 id=
"entry-record">Entry Record
</h3>
1879 <p>The
<em>entry
</em> record defines a name for a function address.
</p>
1880 <p><strong>Syntax
</strong>:
</p>
1881 <pre class=
"prettyprint">
1882 V :
"NAME
";
<A
>
1884 <p><strong>Record
</strong>:
</p>
1885 <pre class=
"prettyprint">
1886 AA:
<1, B1, ... , BN
>
1888 <p><strong>Semantics
</strong>:
</p>
1889 <p>The
<em>entry
</em> record defines a name
<code>NAME
</code> for function address
<code>V
</code>.
<code>NAME
</code>
1890 is a sequence of ASCII characters
<code>B1
</code> through
<code>BN
</code>.
</p>
1891 <p><strong>Examples
</strong>:
</p>
1892 <pre class=
"prettyprint">
1893 72:
0|
3:
<8,
4,
0,
1,
0> | declare external
1894 | | void
@f0(i32, i32, i32, i32, i1);
1895 76:
6|
3:
<8,
4,
0,
1,
0> | declare external
1896 | | void
@f1(i32, i32, i32, i32, i1);
1897 81:
4|
3:
<8,
5,
0,
0,
0> | define external void
@f2(i32);
1898 86:
2|
1:
<65535,
19,
2> | globals { // BlockID =
19
1899 92:
0|
3:
<5,
0> | count
0;
1900 94:
4|
0:
<65534> | }
1901 96:
0|
1:
<65535,
14,
2> | valuesymtab { // BlockID =
14
1902 104:
0|
3:
<1,
1,
108,
108,
118, |
@f1 :
"llvm.memmove.p0i8.p0i8.i32
";
1903 |
109,
46,
109,
101, |
1904 |
109,
109,
111,
118, |
1905 |
101,
46,
112,
48, |
1906 |
105,
56,
46,
112,
48,|
1907 |
105,
56,
46,
105,
51,|
1909 145:
4|
3:
<1,
2,
95,
115,
116, |
@f2 :
"_start
";
1910 |
97,
114,
116> |
1911 157:
0|
3:
<1,
0,
108,
108,
118, |
@f0 :
"llvm.memcpy.p0i8.p0i8.i32
";
1912 |
109,
46,
109,
101, |
1913 |
109,
99,
112,
121, |
1914 |
46,
112,
48,
105,
56,|
1915 |
46,
112,
48,
105,
56,|
1916 |
46,
105,
51,
50> |
1917 197:
0|
0:
<65534> | }
1919 <h2 id=
"module-block"><span id=
"link-for-module-block"></span>Module Block
</h2>
1920 <p>The module block, like all blocks, is enclosed in a pair of
1921 <a class=
"reference internal" href=
"#link-for-enter-block-record-section"><em>enter
</em></a> /
1922 <a class=
"reference internal" href=
"#link-for-exit-block-record-section"><em>exit
</em></a> records, using block ID
8. A
1923 well-formed module block consists of the following records (in order):
</p>
1924 <dl class=
"docutils">
1925 <dt>A version record
</dt>
1926 <dd>The
<a class=
"reference internal" href=
"#link-for-version-record"><em>version record
</em></a> communicates which version
1927 of the PNaCl bitcode reader/writer should be used. Note that this is
1928 different than the PNaCl bitcode (ABI) version. The PNaCl bitcode (ABI)
1929 version defines what is expected in records, and is defined in the header
1930 record of the bitcode file. The version record defines the version of the
1931 PNaCl bitcode reader/writer to use to convert records into bit sequences.
</dd>
1932 <dt>Optional local abbreviations
</dt>
1933 <dd>Defines a list of local
<a class=
"reference internal" href=
"#link-for-abbreviations-section"><em>abbreviations
</em></a>
1934 to use for records within the module block.
</dd>
1935 <dt>An abbreviations block
</dt>
1936 <dd>The
<a class=
"reference internal" href=
"#link-for-abbreviations-block-section"><em>abbreviations block
</em></a> defines
1937 user-defined, global abbreviations that are used to convert PNaCl records to
1938 bit sequences in blocks following the abbreviations block.
</dd>
1939 <dt>A types block
</dt>
1940 <dd>The
<a class=
"reference internal" href=
"#link-for-types-block-section"><em>types block
</em></a> defines the set of all
1941 types used in the program.
</dd>
1942 <dt>A non-empty sequence of function address records
</dt>
1943 <dd>Each record defines a
<a class=
"reference internal" href=
"#link-for-function-address-section"><em>function
1944 address
</em></a> used by the program. Function
1945 addresses must either be external, or defined internally by the program. If
1946 they are defined by the program, there must be a
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function
1947 block
</em></a> (appearing later in the module) that
1948 defines the sequence of instructions for each defined function.
</dd>
1949 <dt>A globals block defining the global variables.
</dt>
1950 <dd>This
<a class=
"reference internal" href=
"#link-for-globals-block-section"><em>block
</em></a> defines the set of
1951 global
<a class=
"reference internal" href=
"#link-for-global-variable-address"><em>variable
</em></a> and
1952 <a class=
"reference internal" href=
"#link-for-global-constant-address"><em>constant
</em></a> addresses used by the
1953 program. In addition to the addresses, each global variable also defines how
1954 the corresponding global variable is initialized.
</dd>
1955 <dt>An optional value symbol table block.
</dt>
1956 <dd>This
<a class=
"reference internal" href=
"#link-for-valuesymtab-block-section"><em>block
</em></a>, if defined, provides
1957 textual names for
<a class=
"reference internal" href=
"#link-for-function-address-section"><em>function
1958 addresses
</em></a> (previously defined in the
1959 module). Note that only names for intrinsic functions and the start function
1961 <dt>A sequence of function blocks.
</dt>
1962 <dd>Each
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function block
</em></a> defines the
1963 corresponding intermediate representation for each defined function. The
1964 order of function blocks is used to associate them with
<a class=
"reference internal" href=
"#link-for-function-address-section"><em>function
1965 addresses
</em></a>. The order of the defined
1966 function blocks must follow the same order as the corresponding function
1967 addresses defined in the module block.
</dd>
1969 <p>Descriptions of the
<a class=
"reference internal" href=
"#link-for-abbreviations-section"><em>abbreviations
</em></a>,
1970 <a class=
"reference internal" href=
"#link-for-types-block-section"><em>types
</em></a>,
1971 <a class=
"reference internal" href=
"#link-for-globals-block-section"><em>globals
</em></a>,
<a class=
"reference internal" href=
"#link-for-valuesymtab-block-section"><em>value symbol
1973 <a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function
</em></a> blocks are not provided
1974 here. See the appropriate reference for more details. The following subsections
1975 describe each of the records that can appear in a module block.
</p>
1976 <h3 id=
"version-record"><span id=
"link-for-version-record"></span>Version Record
</h3>
1977 <p>The version record defines the implementation of the PNaCl bitstream
1978 reader/writer to use. That is, the implementation that converts PNaCl records to
1979 bit sequences, and converts them back to PNaCl records. Note that this is
1980 different than the PNaCl version of the bitcode file (encoded in the header
1981 record of the bitcode file). The PNaCl version defines the valid forms of PNaCl
1982 records. The version record is specific to the PNaCl version, and may have
1983 different values for different PNaCl versions.
</p>
1984 <p>Note that currently, only PNaCl bitcode version
2, and version record value
1 is
1986 <p><strong>Syntax
</strong>:
</p>
1987 <pre class=
"prettyprint">
1988 version N;
<A
>
1990 <p><strong>Record
</strong>:
</p>
1991 <pre class=
"prettyprint">
1994 <p><strong>Semantics
</strong>:
</p>
1995 <p>The version record defines which PNaCl reader/writer rules should be
1996 followed.
<code>N
</code> is the version number. Currently
<code>N
</code> must be
1. Future
1997 versions of PNaCl may define additional legal values.
</p>
1998 <p><strong>Constraints
</strong>:
</p>
1999 <pre class=
"prettyprint">
2000 AA == AbbrevIndex(A)
2002 <p><em>Examples
</em>:
</p>
2003 <pre class=
"prettyprint">
2004 16:
0|
1:
<65535,
8,
2> |module { // BlockID =
8
2005 24:
0|
3:
<1,
1> | version
1;
2006 26:
4|
1:
<65535,
0,
2> | abbreviations { // BlockID =
0
2007 36:
0|
0:
<65534> | }
2009 <h3 id=
"function-address"><span id=
"link-for-function-address-section"></span>Function Address
</h3>
2010 <p>A function address record describes a function address.
<em>Defined
</em> function
2011 addresses define
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>implementations
</em></a> while
2012 <em>declared
</em> function addresses do not.
</p>
2013 <p>Since a PNaCl program is assumed to be a complete (statically linked)
2014 executable, All functions should be
<em>defined
</em> and
<em>internal
</em>. The exception to
2015 this are
<a class=
"reference internal" href=
"#link-for-intrinsic-functions-section"><em>intrinsic functions
</em></a>, which
2016 should only be
<em>declared
</em> and
<em>external
</em>, since intrinsic functions will be
2017 automatically converted to appropriate code by the
<a class=
"reference internal" href=
"/native-client/overview.html#link-for-pnacl-translator"><em>PNaCl
2018 translator
</em></a>.
</p>
2019 <p>The implementation of a
<em>defined
</em> function address is provided by a
2020 corresponding function block, appearing later in the module block. The
2021 association of a
<em>defined
</em> function address with the corresponding function
2022 block is based on position. The
<em>Nth
</em> defined function address record, in the
2023 module block, has its implementation in the
<em>Nth
</em> function block of that module
2025 <p><strong>Syntax
</strong>:
</p>
2026 <pre class=
"prettyprint">
2027 PN LN T0
@fN ( T1 , ... , TM );
<A
>
2029 <p><strong>Record
</strong>:
</p>
2030 <pre class=
"prettyprint">
2031 AA:
<8, T, C, P, L
>
2033 <p><strong>Semantics
</strong>:
</p>
2034 <p>Describes the function address
<code>@fN
</code>.
<code>PN
</code> is the name that specifies the
2035 prototype value
<code>P
</code> associated with the function. A function address is
2036 <em>defined
</em> only if
<code>P ==
0</code>. Otherwise, it is only
<em>declared
</em>. The type of the
2037 function is
<a class=
"reference internal" href=
"#link-for-function-type"><em>function type
</em></a> <code>@tT
</code>.
<code>L
</code> is the
2038 linkage specification corresponding to name
<code>LN
</code>.
<code>C
</code> is the calling
2039 convention used by the function.
</p>
2040 <p>Note that function signature must be defined by a function type in the types
2041 block. Hence, the return value must either be a primitive type, type
<code>void
</code>,
2042 or a vector type.
</p>
2043 <p>For ordinary functions, integer parameter and types can only be
<code>i32
</code> and
2044 <code>i64
</code>. All other integer types are not allowed. For intrinsic functions, all
2045 integer types are allowed.
</p>
2046 <p>Valid prototype names
<code>PN
</code>, and corresponding
<code>P
</code> values, are:
</p>
2047 <table border=
"1" class=
"docutils">
2050 <thead valign=
"bottom">
2051 <tr class=
"row-odd"><th class=
"head">P
</th>
2052 <th class=
"head">PN
</th>
2055 <tbody valign=
"top">
2056 <tr class=
"row-even"><td>1</td>
2059 <tr class=
"row-odd"><td>0</td>
2064 <p>Valid linkage names
<code>LN
</code>, and corresponding
<code>L
</code> values, are:
</p>
2065 <table border=
"1" class=
"docutils">
2068 <thead valign=
"bottom">
2069 <tr class=
"row-odd"><th class=
"head">L
</th>
2070 <th class=
"head">LN
</th>
2073 <tbody valign=
"top">
2074 <tr class=
"row-even"><td>3</td>
2077 <tr class=
"row-odd"><td>0</td>
2082 <p>Currently, only one calling convention
<code>C
</code> is supported:
</p>
2083 <table border=
"1" class=
"docutils">
2086 <thead valign=
"bottom">
2087 <tr class=
"row-odd"><th class=
"head">C
</th>
2088 <th class=
"head">Calling Convention
</th>
2091 <tbody valign=
"top">
2092 <tr class=
"row-even"><td>0</td>
2093 <td>C calling convention
</td>
2097 <p><strong>Constraints
</strong>:
</p>
2098 <pre class=
"prettyprint">
2099 AA = AbbrevIndex(A)
&
2100 T = TypeID(TypeOf(T0 ( T1 , ... , TN )))
&
2101 N = NumFuncAddresses
2103 <p><strong>Updates
</strong>:
</p>
2104 <pre class=
"prettyprint">
2106 TypeOf(
@fN) = TypeOf(TypeID(i32));
2107 TypeOfFcn(
@fN) = TypeOf(
@tT);
2110 DefiningFcnIDs +=
@FN;
2111 ++NumDefinedFunctionAddresses;
2113 <p><strong>Examples
</strong>:
</p>
2114 <pre class=
"prettyprint">
2115 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
2116 48:
0|
3:
<1,
7> | count
7;
2117 50:
4|
3:
<7,
32> |
@t0 = i32;
2118 53:
6|
3:
<3> |
@t1 = float;
2119 55:
4|
3:
<4> |
@t2 = double;
2120 57:
2|
3:
<2> |
@t3 = void;
2121 59:
0|
3:
<21,
0,
2,
1> |
@t4 = double (float);
2122 63:
0|
3:
<21,
0,
0,
0,
1,
0,
2>|
@t5 =
2123 | | i32 (i32, float, i32, double);
2124 69:
2|
3:
<21,
0,
3> |
@t6 = void ();
2125 72:
4|
0:
<65534> | }
2126 76:
0|
3:
<8,
4,
0,
1,
0> | declare external double
@f0(float);
2127 80:
6|
3:
<8,
5,
0,
1,
0> | declare external
2128 | | i32
@f1(i32, float, i32, double);
2129 85:
4|
3:
<8,
6,
0,
0,
0> | define external void
@f2();
2131 <h2 id=
"constants-blocks"><span id=
"link-for-constants-block-section"></span>Constants Blocks
</h2>
2132 <p>Constants blocks define literal constants used within each function. Its intent
2133 is to define them once, before instructions. A constants block can only appear
2134 in a
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function block
</em></a>, and must appear
2135 before any instructions in the function block.
</p>
2136 <p>Currently, only integer literals, floating point literals, and undefined vector
2137 constants can be defined.
</p>
2138 <p>To minimize type information put in a constants block, the type information is
2139 separated from the constants. This allows a sequence of constants to be given
2140 the same type. This is done by defining a
<a class=
"reference internal" href=
"#link-for-constants-set-type-record"><em>set type
2141 record
</em></a>, followed by a sequence of literal
2142 constants. These literal constants all get converted to the type of the
2143 preceding set type record.
</p>
2144 <p>Note that constants that are used for switch case selectors should not be added
2145 to the constants block, since the switch instruction contains the constants used
2146 for case selectors. All other constants in the function block must be put into a
2147 constants block, so that instructions can use them.
</p>
2148 <p>To make this more concrete, consider the following example constants block:
</p>
2149 <pre class=
"prettyprint">
2150 106:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
2151 116:
0|
3:
<1,
0> | i32:
2152 118:
4|
3:
<4,
2> | %c0 = i32
1;
2153 121:
0|
3:
<4,
4> | %c1 = i32
2;
2154 123:
4|
3:
<1,
2> | i8:
2155 126:
0|
3:
<4,
8> | %c2 = i8
4;
2156 128:
4|
3:
<4,
6> | %c3 = i8
3;
2157 131:
0|
3:
<1,
1> | float:
2158 133:
4|
3:
<6,
1065353216> | %c4 = float
1;
2159 139:
6|
0:
<65534> | }
2161 <h3 id=
"set-type-record"><span id=
"link-for-constants-set-type-record"></span>Set Type Record
</h3>
2162 <p>The
<em>set type
</em> record defines the type to use for the (immediately) succeeding
2164 <p><strong>Syntax
</strong>:
</p>
2165 <pre class=
"prettyprint">
2168 <p><strong>Record
</strong>:
</p>
2169 <pre class=
"prettyprint">
2172 <p><strong>Semantics
</strong>:
</p>
2173 <p>The
<em>set type
</em> record defines type
<code>T
</code> to be used to type the (immediately)
2174 succeeding literals.
<code>T
</code> must be a non-void primitive value type or a vector
2176 <p><strong>Constraints
</strong>:
</p>
2177 <pre class=
"prettyprint">
2180 <p><strong>Updates
</strong>:
</p>
2181 <pre class=
"prettyprint">
2182 ConstantsSetType = T;
2184 <p><strong>Examples
</strong>:
</p>
2185 <pre class=
"prettyprint">
2186 106:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
2187 116:
0|
3:
<1,
0> | i32:
2188 118:
4|
3:
<4,
2> | %c0 = i32
1;
2189 121:
0|
3:
<4,
4> | %c1 = i32
2;
2190 123:
4|
3:
<1,
2> | i8:
2191 126:
0|
3:
<4,
8> | %c2 = i8
4;
2192 128:
4|
3:
<4,
6> | %c3 = i8
3;
2193 131:
0|
3:
<1,
1> | float:
2194 133:
4|
3:
<6,
1065353216> | %c4 = float
1;
2195 139:
6|
0:
<65534> | }
2197 <h3 id=
"undefined-literal"><span id=
"link-for-undefined-literal"></span>Undefined Literal
</h3>
2198 <p>The
<em>undefined
</em> literal record creates an undefined literal for the type
<em>T
</em>
2199 defined by the preceding
<em>set type
</em> record.
</p>
2200 <p>Note: See
<a class=
"reference internal" href=
"#link-for-insert-element-instruction-section"><em>insert element
2201 instruction
</em></a> for an example of how
2202 you would use the undefined literal with vector types.
</p>
2203 <p><strong>Syntax
</strong>:
</p>
2204 <pre class=
"prettyprint">
2205 %cN = T undef;
<50>
2207 <p><strong>Record
</strong>:
</p>
2208 <pre class=
"prettyprint">
2211 <p><strong>Semantics
</strong>:
</p>
2212 <p>The
<em>undefined
</em> literal record creates an undefined literal constant
<code>%cN
</code> for
2213 type
<code>T
</code>.
<code>T
</code> must be the type defined by the preceding
<em>set type
</em> record,
2214 and be a primitive value type or a vector type.
</p>
2215 <p><strong>Constraints
</strong>:
</p>
2216 <pre class=
"prettyprint">
2217 N == NumFcnConsts
&
2218 T == ConstantsSetType
&
2219 IsPrimitive(T) or IsVector(T)
2221 <p><strong>Updates
</strong>:
</p>
2222 <pre class=
"prettyprint">
2226 <p><strong>Examples
</strong>:
</p>
2227 <pre class=
"prettyprint">
2228 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
2229 48:
0|
3:
<1,
5> | count
5;
2230 50:
4|
3:
<7,
32> |
@t0 = i32;
2231 53:
6|
3:
<3> |
@t1 = float;
2232 55:
4|
3:
<2> |
@t2 = void;
2233 57:
2|
3:
<12,
4,
0> |
@t3 =
<4 x i32
>;
2234 60:
4|
3:
<21,
0,
2> |
@t4 = void ();
2235 63:
6|
0:
<65534> | }
2237 106:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
2238 116:
0|
3:
<1,
0> | i32:
2239 118:
4|
3:
<3> | %c0 = i32 undef;
2240 120:
2|
3:
<4,
2> | %c1 = i32
1;
2241 122:
6|
3:
<1,
3> |
<4 x i32
>:
2242 125:
2|
3:
<3> | %c2 =
<4 x i32
> undef;
2243 127:
0|
3:
<1,
1> | float:
2244 129:
4|
3:
<3> | %c3 = float undef;
2245 131:
2|
0:
<65534> | }
2247 <h3 id=
"integer-literal"><span id=
"link-for-integer-literal"></span>Integer Literal
</h3>
2248 <p>The
<em>integer literal
</em> record creates an integer literal for the integer type
<em>T
</em>
2249 defined by the preceding
<em>set type
</em> record.
</p>
2250 <p><strong>Syntax
</strong>:
</p>
2251 <pre class=
"prettyprint">
2252 %cN = T V;
<A
>
2254 <p><strong>Record
</strong>:
</p>
2255 <pre class=
"prettyprint">
2258 <p><strong>Semantics
</strong>:
</p>
2259 <p>The
<em>integer literal
</em> record creates an integer literal constant
<code>%cN
</code> for
2260 type
<code>T
</code>.
<code>T
</code> must be the type defined by the preceding
<em>set type
</em> record,
2261 and an integer type. The literal
<code>V
</code> can be signed, but must be definable by
2262 type
<code>T
</code>.
</p>
2263 <p><strong>Constraints
</strong>:
</p>
2264 <pre class=
"prettyprint">
2265 N == NumFcnConsts
&
2266 T == ConstantsSetType
&
2267 VV == SignRotate(V)
&
2270 <p><strong>Updates
</strong>:
</p>
2271 <pre class=
"prettyprint">
2274 <p><strong>Examples
</strong>:
</p>
2275 <pre class=
"prettyprint">
2276 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
2277 48:
0|
3:
<1,
7> | count
7;
2278 50:
4|
3:
<7,
8> |
@t0 = i8;
2279 53:
0|
3:
<7,
16> |
@t1 = i16;
2280 55:
4|
3:
<7,
32> |
@t2 = i32;
2281 58:
6|
3:
<7,
64> |
@t3 = i64;
2282 62:
0|
3:
<7,
1> |
@t4 = i1;
2283 64:
4|
3:
<2> |
@t5 = void;
2284 66:
2|
3:
<21,
0,
5> |
@t6 = void ();
2285 69:
4|
0:
<65534> | }
2287 114:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
2288 124:
0|
3:
<1,
0> | i8:
2289 126:
4|
3:
<4,
2> | %c0 = i8
1;
2290 129:
0|
3:
<4,
4> | %c1 = i8
2;
2291 131:
4|
3:
<1,
1> | i16:
2292 134:
0|
3:
<4,
6> | %c2 = i16
3;
2293 136:
4|
3:
<4,
8> | %c3 = i16
4;
2294 139:
0|
3:
<1,
2> | i32:
2295 141:
4|
3:
<4,
10> | %c4 = i32
5;
2296 144:
0|
3:
<4,
12> | %c5 = i32
6;
2297 146:
4|
3:
<1,
3> | i64:
2298 149:
0|
3:
<4,
3> | %c6 = i64 -
1;
2299 151:
4|
3:
<4,
5> | %c7 = i64 -
2;
2300 154:
0|
3:
<1,
4> | i1:
2301 156:
4|
3:
<4,
3> | %c8 = i1
1;
2302 159:
0|
3:
<4,
0> | %c9 = i1
0;
2303 161:
4|
0:
<65534> | }
2305 <h3 id=
"floating-point-literal">Floating Point Literal
</h3>
2306 <p>The
<em>floating point literal
</em> record creates a floating point literal for the
2307 floating point type
<em>T
</em> defined by the preceding
<em>set type
</em> record.
</p>
2308 <p><strong>Syntax
</strong>:
</p>
2309 <pre class=
"prettyprint">
2310 %cN = T V;
<A
>
2312 <p><strong>Record
</strong>:
</p>
2313 <pre class=
"prettyprint">
2316 <p><strong>Semantics
</strong>:
</p>
2317 <p>The
<em>floating point literal
</em> record creates a floating point literal constant
2318 <code>%cN
</code> for type
<code>T
</code>.
<code>T
</code> must the type type defined by the preceding
<em>set
2319 type
</em> record, and be a floating point type. The literal
<code>V
</code> is the floating
2320 value to be defined. The value
<code>VV
</code> if the corresponding IEEE unsigned integer
2321 that defines value
<code>V
</code>. That is, the literal
<code>VV
</code> must be a valid IEEE
754
2322 32-bit (unsigned integer) value if
<code>T
</code> is
<code>float
</code>, and a valid IEEE
754
2323 64-bit (unsigned integer) value if
<code>T
</code> is
<code>double
</code>.
</p>
2324 <p><strong>Constraints
</strong>:
</p>
2325 <pre class=
"prettyprint">
2327 T == ConstantsSetType
2330 <p><strong>Updates
</strong>:
</p>
2331 <pre class=
"prettyprint">
2334 <p><strong>Examples
</strong>:
</p>
2335 <pre class=
"prettyprint">
2336 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
2337 48:
0|
3:
<1,
4> | count
4;
2338 50:
4|
3:
<3> |
@t0 = float;
2339 52:
2|
3:
<4> |
@t1 = double;
2340 54:
0|
3:
<2> |
@t2 = void;
2341 55:
6|
3:
<21,
0,
2> |
@t3 = void ();
2342 59:
0|
0:
<65534> | }
2344 102:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
2345 112:
0|
3:
<1,
0> | float:
2346 114:
4|
3:
<6,
0> | %c0 = float
0;
2347 117:
0|
3:
<6,
1065353216> | %c1 = float
1;
2348 123:
2|
3:
<6,
1088421888> | %c2 = float
7;
2349 130:
2|
3:
<6,
1090519040> | %c3 = float
8;
2350 137:
2|
3:
<3> | %c4 = float undef;
2351 139:
0|
3:
<6,
2143289344> | %c5 = float nan;
2352 146:
0|
3:
<6,
2139095040> | %c6 = float inf;
2353 153:
0|
3:
<6,
4286578688> | %c7 = float -inf;
2354 160:
0|
3:
<1,
1> | double:
2355 162:
4|
3:
<6, | %c8 = double
1;
2356 |
4607182418800017408> |
2357 174:
0|
3:
<6,
0> | %c9 = double
0;
2358 176:
4|
3:
<6, | %c10 = double
5;
2359 |
4617315517961601024> |
2360 188:
0|
3:
<6, | %c11 = double
6;
2361 |
4618441417868443648> |
2362 199:
4|
3:
<6, | %c12 = double nan;
2363 |
9221120237041090560> |
2364 211:
0|
3:
<6, | %c13 = double inf;
2365 |
9218868437227405312> |
2366 222:
4|
3:
<6, | %c14 = double -inf;
2367 |
18442240474082181120>|
2368 234:
0|
0:
<65534> | }
2370 <h2 id=
"function-blocks"><span id=
"link-for-function-blocks-section"></span>Function Blocks
</h2>
2371 <p>A function block defines the implementation of a defined
<a class=
"reference internal" href=
"#link-for-function-address-section"><em>function
2372 address
</em></a>. The function address it defines is
2373 based on the position of the corresponding defined function address. The Nth
2374 defined function address always corresponds to the Nth function block in the
2376 <p>A function implementation contains a list of basic blocks, forming the control
2377 flow graph. Each
<em>basic block
</em> contains a list of instructions, and ends with a
2378 <a class=
"reference internal" href=
"#link-for-terminator-instruction-section"><em>terminator instruction
</em></a>
2380 <p>Basic blocks are not represented by records. Rather, context is implicit. The
2381 first basic block begins with the first instruction record in the function
2382 block. Block boundaries are determined by terminator instructions. The
2383 instruction that follows a terminator instruction begins a new basic block.
</p>
2384 <p>The first basic block in a function is special in two ways: it is immediately
2385 executed on entrance to the function, and it is not allowed to have predecessor
2386 basic blocks (i.e. there can
’t be any branches to the entry block of a
2387 function). Because the entry block has no predecessors, it also can
’t have any
2388 <a class=
"reference internal" href=
"#link-for-phi-instruction-section"><em>phi
</em></a> instructions.
</p>
2389 <p>The parameters are implied by the type of the corresponding function
2390 address. One parameter is defined for each argument of the function
<a class=
"reference internal" href=
"#link-for-function-type"><em>type
2391 signature
</em></a> of the corresponding
<a class=
"reference internal" href=
"#link-for-function-address-section"><em>function
2392 address
</em></a>.
</p>
2393 <p>The number of basic blocks is defined by the
<a class=
"reference internal" href=
"#link-for-basic-blocks-count"><em>count
2394 record
</em></a>. Each
<a class=
"reference internal" href=
"#link-for-terminator-instruction-section"><em>terminator
2395 instruction
</em></a> ends the current basic
2396 block, and the next instruction begins a new basic block. Basic blocks are
2397 numbered by the order they appear (starting with index
0). Basic block IDs have
2398 the form
<code>%bN
</code>, where
<code>N
</code> corresponds to the position of the basic block
2399 within the function block.
</p>
2400 <p>Each instruction, within a function block, corresponds to a corresponding PNaCl
2401 record. The layout of a function block is the (basic block) count record,
2402 followed by a sequence of instruction records.
</p>
2403 <p>For readability, PNaClAsm introduces basic block IDs. These basic block IDs do
2404 not correspond to PNaCl records, since basic block boundaries are defined
2405 implicitly, after terminator instructions. They appear only for readability.
</p>
2406 <p>Operands of instructions are defined using an
<a class=
"reference internal" href=
"#link-for-absolute-index-section"><em>absolute
2407 index
</em></a>. This absolute index implicitly encodes
2408 function addresses, global addresses, parameters, constants, and instructions
2409 that generate values. The encoding takes advantage of the implied ordering of
2410 these values in the bitcode file, defining a contiguous sequence of indices for
2411 each kind of identifier. That is, indices are ordered by putting function
2412 address identifiers first, followed by global address identifiers, followed by
2413 parameter identifiers, followed by constant identifiers, and lastly instruction
2414 value identifiers.
</p>
2415 <p>To save space in the encoded bitcode file, most operands are encoded using a
2416 <a class=
"reference internal" href=
"#link-for-relative-index"><em>relative index
</em></a> value, rather than
2417 <a class=
"reference internal" href=
"#link-for-absolute-index-section"><em>absolute
</em></a>. This
2418 is done because most instruction operands refer to values defined earlier in the
2419 (same) basic block. As a result, the relative distance (back) from the next
2420 value defining instruction is frequently a small number. Small numbers tend to
2421 require fewer bits when they are converted to bit sequences.
</p>
2422 <p>Note that instructions that can appear in a function block are defined in
2423 sections
<a class=
"reference internal" href=
"#link-for-terminator-instruction-section"><em>Terminator Instructions
</em></a>,
2424 <a class=
"reference internal" href=
"#link-for-integer-binary-instructions"><em>Integer Binary Instructions
</em></a>,
2425 <a class=
"reference internal" href=
"#link-for-floating-point-binary-instructions"><em>Floating Point Binary Instructions
</em></a>,
2426 <a class=
"reference internal" href=
"#link-for-memory-creation-and-access-instructions"><em>Memory Creation and Access Instructions
</em></a>,
2427 <a class=
"reference internal" href=
"#link-for-conversion-instructions"><em>Conversion Instructions
</em></a>,
<a class=
"reference internal" href=
"#link-for-compare-instructions"><em>Comparison Instructions
</em></a>,
2428 <a class=
"reference internal" href=
"#link-for-vector-instructions"><em>Vector Instructions
</em></a>, and
2429 <a class=
"reference internal" href=
"#link-for-other-pnaclasm-instructions"><em>Other Instructions
</em></a>.
</p>
2430 <p>The following subsections define the remaining records that can appear in a
2432 <h3 id=
"function-enter">Function Enter
</h3>
2433 <p>PNaClAsm defines a function enter block construct. The corresponding record is
2434 simply an
<a class=
"reference internal" href=
"#link-for-enter-block-record-section"><em>enter block
</em></a> record, with
2435 BlockID value
<code>12</code>. All context about the defining address is implicit by the
2436 position of the function block, and the corresponding defining
<a class=
"reference internal" href=
"#link-for-function-address-section"><em>function
2437 address
</em></a>. To improve readability, PNaClAsm
2438 includes the function signature into the syntax rule.
</p>
2439 <p><strong>Syntax
</strong>:
</p>
2440 <pre class=
"prettyprint">
2441 function TR
@fN ( T0 %p0, ... , TM %pM ) {
<B
>
2443 <p><strong>Record
</strong>:
</p>
2444 <pre class=
"prettyprint">
2445 1:
<65535,
12, B
>
2447 <p><strong>Semantics
</strong>:
</p>
2448 <p><code>B
</code> is the number of bits reserved for abbreviations in the block. If it is
2449 omitted,
2 is assumed. See
<a class=
"reference internal" href=
"#link-for-enter-block-record-section"><em>enter
</em></a>
2450 block records for more details.
</p>
2451 <p>The value of
<code>N
</code> corresponds to the positional index of the corresponding
2452 defining function address this block is associated with.
<code>M
</code> is the number of
2453 defined parameters (minus one) in the function heading.
</p>
2454 <p><strong>Constraints
</strong>:
</p>
2455 <pre class=
"prettyprint">
2456 N == NumFcnImpls
&
2457 @fN in DefiningFcnIDs
&
2458 TypeOfFcn(
@fN) == TypeOf(TypeID(TR (T0, ... , TM)))
2460 <p><strong>Updates
</strong>:
</p>
2461 <pre class=
"prettyprint">
2463 EnclosingFcnID =
@fN;
2468 TypeOf(%pI) = TypeOf(TypeID(TI));
2470 <p><strong>Examples
</strong>:
</p>
2471 <pre class=
"prettyprint">
2472 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
2473 48:
0|
3:
<1,
4> | count
4;
2474 50:
4|
3:
<7,
32> |
@t0 = i32;
2475 53:
6|
3:
<2> |
@t1 = void;
2476 55:
4|
3:
<21,
0,
1> |
@t2 = void ();
2477 58:
6|
3:
<21,
0,
0,
0> |
@t3 = i32 (i32);
2478 62:
6|
0:
<65534> | }
2480 104:
0|
1:
<65535,
12,
2> | function void
@f0() {
2482 112:
0|
3:
<1,
1> | blocks
1;
2484 114:
4|
3:
<10> | ret void;
2485 116:
2|
0:
<65534> | }
2486 120:
0|
1:
<65535,
12,
2> | function i32
@f1(i32 %p0) {
2488 128:
0|
3:
<1,
1> | blocks
1;
2490 130:
4|
3:
<10,
1> | ret i32 %p0;
2491 133:
0|
0:
<65534> | }
2493 <h3 id=
"link-for-basic-blocks-count"><span id=
"id3"></span>Count Record
</h3>
2494 <p>The count record, within a function block, defines the number of basic blocks
2495 used to define the function implementation. It must be the first record in the
2497 <p><strong>Syntax
</strong>:
</p>
2498 <pre class=
"prettyprint">
2499 blocks: N;
<A
>
2502 <p><strong>Record
</strong>:
</p>
2503 <pre class=
"prettyprint">
2506 <p><strong>Semantics
</strong>:
</p>
2507 <p>The count record defines the number
<code>N
</code> of basic blocks in the implemented
2509 <p><strong>Constraints
</strong>:
</p>
2510 <pre class=
"prettyprint">
2511 AA == AbbrevIndex(A)
&
2512 ExpectedBasicBlocks == N
&
2515 <p><strong>Updates
</strong>:
</p>
2516 <pre class=
"prettyprint">
2517 104:
0|
1:
<65535,
12,
2> | function void
@f0() {
2519 112:
0|
3:
<1,
1> | blocks
1;
2521 114:
4|
3:
<10> | ret void;
2522 116:
2|
0:
<65534> | }
2523 120:
0|
1:
<65535,
12,
2> | function i32
@f1(i32 %p0) {
2525 128:
0|
3:
<1,
1> | blocks
1;
2527 130:
4|
3:
<10,
1> | ret i32 %p0;
2528 133:
0|
0:
<65534> | }
2530 <h2 id=
"terminator-instructions"><span id=
"link-for-terminator-instruction-section"></span>Terminator Instructions
</h2>
2531 <p>Terminator instructions are instructions that appear in a
<a class=
"reference internal" href=
"#link-for-function-blocks-section"><em>function
2532 block
</em></a>, and define the end of the current
2533 basic block. A terminator instruction indicates which block should be executed
2534 after the current block is finished. The function block is well formed only if
2535 the number of terminator instructions, in the function block, corresponds to the
2536 value defined by the corresponding function basic block
<a class=
"reference internal" href=
"#link-for-basic-blocks-count"><em>count
2537 record
</em></a>.
</p>
2538 <p>Note that any branch instruction to label
<code>%bN
</code>, where
<code>N
>=
2539 ExpectedBasicBlocks
</code>, is illegal. For ease of readability, this constraint
2540 hasn
’t been put on branch instructions. Rather it is only implied.
</p>
2541 <p>In addition, it must be the case that
<code>NumBasicBlocks
< ExpectedBasicBlocks
</code>,
2542 and will not be listed as a constraint. Further, if
<code>B = NumBasicBlocks +
1</code>
2543 is the number associated with the next basic block. Label
<cite>%bB:
</cite> only appears
2545 <pre class=
"prettyprint">
2546 B
< ExpectedBasicBlocks
2548 <p>That is, the label is omitted only if this terminator instruction is the last
2549 instruction in the function block.
</p>
2550 <h3 id=
"return-void-instruction">Return Void Instruction
</h3>
2551 <p>The return void instruction is used to return control from a function back to
2552 the caller, without returning any value.
</p>
2553 <p><strong>Syntax
</strong>:
</p>
2554 <pre class=
"prettyprint">
2558 <p><strong>Record
</strong>:
</p>
2559 <pre class=
"prettyprint">
2562 <p><strong>Semantics
</strong>:
</p>
2563 <p>The return void instruction returns control to the calling function.
</p>
2564 <p><strong>Constraints
</strong>:
</p>
2565 <pre class=
"prettyprint">
2566 AA == AbbrevIndex(A)
&
2567 B == NumBasicBlocks +
1 &
2568 ReturnType(TypeOf(EnclosingFcnID)) == void
2570 <p><strong>Updates
</strong>:
</p>
2571 <pre class=
"prettyprint">
2574 <p><strong>Examples
</strong>:
</p>
2575 <pre class=
"prettyprint">
2576 104:
0|
1:
<65535,
12,
2> | function void
@f0() {
2578 112:
0|
3:
<1,
1> | blocks
1;
2580 114:
4|
3:
<10> | ret void;
2581 116:
2|
0:
<65534> | }
2583 <h3 id=
"return-value-instruction">Return Value Instruction
</h3>
2584 <p>The return value instruction is used to return control from a function back to
2585 the caller, including a value. The value must correspond to the return type of
2586 the enclosing function.
</p>
2587 <p><strong>Syntax
</strong>:
</p>
2588 <pre class=
"prettyprint">
2592 <p><strong>Record
</strong>:
</p>
2593 <pre class=
"prettyprint">
2596 <p><strong>Semantics
</strong>:
</p>
2597 <p>The return value instruction returns control to the calling function, returning
2598 the provided value.
</p>
2599 <p><code>V
</code> is the value to return. Type
<code>T
</code> must be of the type returned by the
2600 function. It must also be the type associated with value
<code>V
</code>.
</p>
2601 <p>The return type
<code>T
</code> must either be a (non-void) primitive type, or a vector
2602 type. If the function block is implementing an ordinary function, and the return
2603 type is an integer type, it must be either
<code>i32
</code> or
<code>i64
</code>.
</p>
2604 <p><strong>Constraints
</strong>:
</p>
2605 <pre class=
"prettyprint">
2606 AA == AbbrevIndex(A)
&
2607 VV == RelativeIndex(V)
&
2608 B == NumBasicBlocks +
1 &
2609 T == TypeOf(V) == ReturnType(TypeOf(EnclosingFcnID))
2611 <p><strong>Updates
</strong>:
</p>
2612 <pre class=
"prettyprint">
2615 <p><strong>Examples
</strong>:
</p>
2616 <pre class=
"prettyprint">
2617 120:
0|
1:
<65535,
12,
2> | function i32
@f1(i32 %p0) {
2619 128:
0|
3:
<1,
1> | blocks
1;
2621 130:
4|
3:
<10,
1> | ret i32 %p0;
2623 <h3 id=
"unconditional-branch-instruction">Unconditional Branch Instruction
</h3>
2624 <p>The unconditional branch instruction is used to cause control flow to transfer
2625 to a different basic block of the function.
</p>
2626 <p><strong>Syntax
</strong>:
</p>
2627 <pre class=
"prettyprint">
2631 <p><strong>Record
</strong>:
</p>
2632 <pre class=
"prettyprint">
2635 <p><strong>Semantics
</strong>:
</p>
2636 <p>The unconditional branch instruction causes control flow to transfer to basic
2637 block
<code>N
</code>.
</p>
2638 <p><strong>Constraints
</strong>:
</p>
2639 <pre class=
"prettyprint">
2640 AA == AbbrevIndex(A)
&
2641 B == NumBasicBlocks +
1 &
2643 N
< ExpectedBasicBlocks
2645 <p><strong>Updates
</strong>:
</p>
2646 <pre class=
"prettyprint">
2649 <p><strong>Examples
</strong>:
</p>
2650 <pre class=
"prettyprint">
2651 88:
0|
1:
<65535,
12,
2> | function void
@f0() {
2653 96:
0|
3:
<1,
5> | blocks
5;
2655 98:
4|
3:
<11,
3> | br label %b3;
2657 101:
0|
3:
<11,
4> | br label %b4;
2659 103:
4|
3:
<11,
1> | br label %b1;
2661 106:
0|
3:
<11,
2> | br label %b2;
2663 108:
4|
3:
<10> | ret void;
2664 110:
2|
0:
<65534> | }
2666 <h3 id=
"conditional-branch-instruction">Conditional Branch Instruction
</h3>
2667 <p>The conditional branch instruction is used to cause control flow to transfer to
2668 a different basic block of the function, based on a boolean test condition.
</p>
2669 <p><strong>Syntax
</strong>:
</p>
2670 <pre class=
"prettyprint">
2671 br i1 C, %bT, %bBF;
<A
>
2674 <p><strong>Record
</strong>:
</p>
2675 <pre class=
"prettyprint">
2676 AA:
<11, T, F, CC
>
2678 <p><strong>Semantics
</strong>:
</p>
2679 <p>Upon execution of a conditional branch instruction, the
<em>i1
</em> (boolean) argument
2680 <code>C
</code> is evaluated. If the value is
<code>true
</code>, control flows to basic block
2681 <code>%bT
</code>. Otherwise control flows to basic block
<code>%bF
</code>.
</p>
2682 <p><strong>Constraints
</strong>:
</p>
2683 <pre class=
"prettyprint">
2684 AA == AbbrevIndex(A)
&
2685 CC == RelativeIndex(C)
&
2686 B == NumBasicBlocks +
1 &
2688 B1
< ExpectedBasicBlocks
&
2690 B2
< ExpectedBasicBlocks
&
2693 <p><strong>Updates
</strong>:
</p>
2694 <pre class=
"prettyprint">
2697 <p><strong>Examples
</strong>:
</p>
2698 <pre class=
"prettyprint">
2699 92:
0|
1:
<65535,
12,
2> | function void
@f0() {
2701 100:
0|
3:
<1,
5> | blocks
5;
2702 102:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
2703 112:
0|
3:
<1,
1> | i1:
2704 114:
4|
3:
<4,
3> | %c0 = i1
1;
2705 117:
0|
3:
<4,
0> | %c1 = i1
0;
2706 119:
4|
0:
<65534> | }
2708 120:
0|
3:
<11,
3> | br label %b3;
2710 122:
4|
3:
<11,
2,
4,
2> | br i1 %c0, label %b2, label %b4;
2712 126:
4|
3:
<11,
3> | br label %b3;
2714 129:
0|
3:
<10> | ret void;
2716 130:
6|
3:
<11,
2,
3,
1> | br i1 %c1, label %b2, label %b3;
2717 134:
6|
0:
<65534> | }
2719 <h3 id=
"unreachable">Unreachable
</h3>
2720 <p>The unreachable instruction has no defined semantics. The instruction is used to
2721 inform the
<a class=
"reference internal" href=
"/native-client/overview.html#link-for-pnacl-translator"><em>PNaCl translator
</em></a> that control
2722 can
’t reach this instruction.
</p>
2723 <p><strong>Syntax
</strong>:
</p>
2724 <pre class=
"prettyprint">
2725 unreachable;
<A
>
2728 <p><strong>Record
</strong>:
</p>
2729 <pre class=
"prettyprint">
2732 <p><strong>Semantics
</strong>:
</p>
2733 <p>Directive to the
<a class=
"reference internal" href=
"/native-client/overview.html#link-for-pnacl-translator"><em>PNaCl translator
</em></a> that
2734 this instruction is unreachable.
</p>
2735 <p><strong>Constraints
</strong>:
</p>
2736 <pre class=
"prettyprint">
2737 AA == AbbrevIndex(A)
2738 B == NumBasicBlocks +
1 &
2740 <p><strong>Updates
</strong>:
</p>
2741 <pre class=
"prettyprint">
2744 <p><strong>Examples
</strong>:
</p>
2745 <pre class=
"prettyprint">
2746 108:
0|
1:
<65535,
12,
2> | function void
@f0(i32 %p0) {
2748 116:
0|
3:
<1,
5> | blocks
5;
2749 118:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
2750 128:
0|
3:
<1,
2> | i1:
2751 130:
4|
3:
<4,
3> | %c0 = i1
1;
2752 133:
0|
3:
<4,
0> | %c1 = i1
0;
2753 135:
4|
0:
<65534> | }
2755 136:
0|
3:
<11,
1,
2,
2> | br i1 %c0, label %b1, label %b2;
2757 140:
0|
3:
<11,
3,
4,
1> | br i1 %c1, label %b3, label %b4;
2759 144:
0|
3:
<15> | unreachable;
2761 145:
6|
3:
<15> | unreachable;
2763 147:
4|
3:
<10> | ret void;
2764 149:
2|
0:
<65534> | }
2766 <h3 id=
"switch-instruction">Switch Instruction
</h3>
2767 <p>The
<em>switch
</em> instruction transfers control flow to one of several different
2768 places, based on a selector value. It is a generalization of the conditional
2769 branch instruction.
</p>
2770 <p><strong>Syntax
</strong>:
</p>
2771 <pre class=
"prettyprint">
2773 default: br label %bB0;
2774 T V1: br label %bB1;
2776 T VN: br label %bBN;
2780 <p><strong>Record
</strong>:
</p>
2781 <pre class=
"prettyprint">
2782 AA:
<12, TT, B0, N, (
1,
1, VVI, BI |
1 <= i
<= N)
>
2784 <p><strong>Semantics
</strong>:
</p>
2785 <p>The switch instruction transfers control to a basic block in
<code>B0
</code> through
2786 <code>BN
</code>. Value
<code>V
</code> is used to conditionally select which block to branch
2787 to.
<code>T
</code> is the type of
<code>V
</code> and
<code>V1
</code> through
<code>VN
</code>, and must be an integer
2788 type. Value
<code>V1
</code> through
<code>VN
</code> are integers to compare against
<code>V
</code>. If
2789 selector
<code>V
</code> matches
<code>VI
</code> (for some
<code>I
</code>,
<code>1 <= I
<= N
</code>), then the
2790 instruction branches to block
<code>BI
</code>. If
<code>V
</code> is not in
<code>V1
</code> through
<code>VN
</code>,
2791 the instruction branches to block
<code>B0
</code>.
</p>
2792 <p><strong>Constraints
</strong>:
</p>
2793 <pre class=
"prettyprint">
2794 AA == AbbrevIndex(A)
&
2795 B == NumBasicBlocks +
1 &
2796 TT == TypeID(T)
&
2797 VI == SignRotate(VI) for all I,
1 <= I
<= N
&
2799 <p><strong>Updates
</strong>:
</p>
2800 <pre class=
"prettyprint">
2803 <p><strong>Examples
</strong>:
</p>
2804 <pre class=
"prettyprint">
2805 116:
0|
1:
<65535,
12,
2> | function void
@f0(i32 %p0) {
2807 124:
0|
3:
<1,
6> | blocks
6;
2809 126:
4|
3:
<12,
1,
1,
2,
4,
1,
1,| switch i32 %p0 {
2810 |
2,
3,
1,
1,
4,
3,
1, | default: br label %b2;
2811 |
1,
8,
4,
1,
1,
10,
4>| i32
1: br label %b3;
2812 | | i32
2: br label %b3;
2813 | | i32
4: br label %b4;
2814 | | i32
5: br label %b4;
2817 143:
2|
3:
<11,
5> | br label %b5;
2819 145:
6|
3:
<11,
5> | br label %b5;
2821 148:
2|
3:
<11,
5> | br label %b5;
2823 150:
6|
3:
<11,
5> | br label %b5;
2825 153:
2|
3:
<10> | ret void;
2826 155:
0|
0:
<65534> | }
2827 156:
0|
1:
<65535,
12,
2> | function void
@f1(i64 %p0) {
2829 164:
0|
3:
<1,
6> | blocks
6;
2831 166:
4|
3:
<12,
2,
1,
2,
4,
1,
1,| switch i64 %p0 {
2832 |
2,
3,
1,
1,
4,
3,
1, | default: br label %b2;
2833 |
1,
8,
4,
1,
1, | i64
1: br label %b3;
2834 |
39777555332,
4> | i64
2: br label %b3;
2835 | | i64
4: br label %b4;
2836 | | i64
19888777666: br label %b4;
2839 188:
4|
3:
<11,
5> | br label %b5;
2841 191:
0|
3:
<11,
5> | br label %b5;
2843 193:
4|
3:
<11,
5> | br label %b5;
2845 196:
0|
3:
<11,
5> | br label %b5;
2847 198:
4|
3:
<10> | ret void;
2848 200:
2|
0:
<65534> | }
2850 <h2 id=
"integer-binary-instructions"><span id=
"link-for-integer-binary-instructions"></span>Integer Binary Instructions
</h2>
2851 <p>Binary instructions are used to do most of the computation in a program. This
2852 section focuses on binary instructions that operator on integer values, or
2853 vectors of integer values.
</p>
2854 <p>All binary operations require two operands of the same type, execute an
2855 operation on them, and produce a value. The value may represent multiple values
2856 if the type is a vector type. The result value always has the same type as its
2858 <p>Some integer binary operations can be applied to both signed and unsigned
2859 integers. Others, the sign is significant. In general, if the sign plays a role
2860 in the instruction, the sign information is encoded into the name of the
2862 <p>For most binary operations (except some of the logical operations), integer
2863 type i1 is disallowed.
</p>
2864 <h3 id=
"integer-add">Integer Add
</h3>
2865 <p>The integer add instruction returns the sum of its two arguments. Both arguments
2866 and the result must be of the same type. That type must be integer, or an
2867 integer vector type.
</p>
2868 <p><strong>Syntax
</strong>:
</p>
2869 <pre class=
"prettyprint">
2870 %vN = add T V1, V2;
<A
>
2872 <p><strong>Record
</strong>:
</p>
2873 <pre class=
"prettyprint">
2874 AA:
<2, VV1, VV2,
0>
2876 <p><strong>Semantics
</strong>:
</p>
2877 <p>The integer add instruction returns the sum of its two arguments. Arguments
2878 <code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code>, must be of type
<code>T
</code>.
<code>T
</code> must be
2879 an integer type, or an integer vector type.
<code>N
</code> is defined by the record
2880 position, defining the corresponding value generated by the instruction.
</p>
2881 <p>The result returned is the mathematical result modulo
2<sup>n
</sup>, where
<code>n
</code>
2882 is the bit width of the integer result.
</p>
2883 <p>Because integers are assumed to use a two
’s complement representation,
2884 this instruction is appropriate for both signed and unsigned integers.
</p>
2885 <p>In the add instruction, integer type
<code>i1
</code> (and a vector of integer type
2886 <code>i1
</code>) is disallowed.
</p>
2887 <p><strong>Constraints
</strong>:
</p>
2888 <pre class=
"prettyprint">
2889 AA == AbbrevIndex(A)
&
2890 VV1 == RelativeIndex(V1)
&
2891 VV2 == RelativeIndex(V2)
&
2892 T == TypeOf(V1) == TypeOf(V2)
&
2893 IsInteger(UnderlyingType(T))
&
2894 UnderlyingType(T) != i1
&
2897 <p><strong>Updates
</strong>:
</p>
2898 <pre class=
"prettyprint">
2902 <p><strong>Examples
</strong>:
</p>
2903 <pre class=
"prettyprint">
2904 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
2906 104:
0|
3:
<1,
1> | blocks
1;
2908 106:
4|
3:
<2,
2,
1,
0> | %v0 = add i32 %p0, %p1;
2909 110:
4|
3:
<2,
3,
1,
0> | %v1 = add i32 %p0, %v0;
2910 114:
4|
3:
<10,
1> | ret i32 %v1;
2911 117:
0|
0:
<65534> | }
2913 <h3 id=
"integer-subtract">Integer Subtract
</h3>
2914 <p>The integer subtract instruction returns the difference of its two arguments.
2915 Both arguments and the result must be of the same type. That type must be
2916 integer, or an integer vector type.
</p>
2917 <p>Note: Since there isn
’t a negate instruction, subtraction from constant zero
2918 should be used to negate values.
</p>
2919 <p><strong>Syntax
</strong>:
</p>
2920 <pre class=
"prettyprint">
2921 %vN = sub T V1, V2;
<A
>
2923 <p><strong>Record
</strong>:
</p>
2924 <pre class=
"prettyprint">
2925 AA:
<2, VV1, VV2,
1>
2927 <p><strong>Semantics
</strong>:
</p>
2928 <p>The integer subtract returns the difference of its two arguments. Arguments
2929 <code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code> must be of type
<code>T
</code>.
<code>T
</code> must be
2930 an integer type, or an integer vector type.
<code>N
</code> is defined by the record
2931 position, defining the corresponding value generated by the instruction.
</p>
2932 <p>The result returned is the mathematical result modulo
2<sup>n
</sup>, where
<code>n
</code>
2933 is the bit width of the integer result.
</p>
2934 <p>Because integers are assumed to use a two
’s complement representation,
2935 this instruction is appropriate for both signed and unsigned integers.
</p>
2936 <p>In the subtract instruction, integer type
<code>i1
</code> (and a vector of integer type
2937 <code>i1
</code>) is disallowed.
</p>
2938 <p><strong>Constraints
</strong>:
</p>
2939 <pre class=
"prettyprint">
2940 AA == AbbrevIndex(A)
&
2941 VV1 == RelativeIndex(V1)
&
2942 VV2 == RelativeIndex(V2)
&
2943 T == TypeOf(V1) == TypeOf(V2)
&
2944 IsInteger(UnderlyingType(T))
&
2945 UnderlyingType(T) != i1
&
2948 <p><strong>Updates
</strong>:
</p>
2949 <pre class=
"prettyprint">
2953 <p><strong>Examples
</strong>:
</p>
2954 <pre class=
"prettyprint">
2955 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
2957 104:
0|
3:
<1,
1> | blocks
1;
2959 106:
4|
3:
<2,
2,
1,
1> | %v0 = sub i32 %p0, %p1;
2960 110:
4|
3:
<2,
3,
1,
1> | %v1 = sub i32 %p0, %v0;
2961 114:
4|
3:
<10,
1> | ret i32 %v1;
2962 117:
0|
0:
<65534> | }
2964 <h3 id=
"integer-multiply">Integer Multiply
</h3>
2965 <p>The integer multiply instruction returns the product of its two arguments. Both
2966 arguments and the result must be of the same type. That type must be integer,
2967 or an integer based vector type.
</p>
2968 <p><strong>Syntax
</strong>:
</p>
2969 <pre class=
"prettyprint">
2970 &vN = mul T V1, V2;
<A
>
2972 <p><strong>Record
</strong>:
</p>
2973 <pre class=
"prettyprint">
2974 AA:
<2, VV1, VV2,
2>
2976 <p><strong>Semantics
</strong>:
</p>
2977 <p>The integer multiply instruction returns the product of its two
2978 arguments. Arguments
<code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code>, must be of type
2979 <code>T
</code>.
<code>T
</code> must be an integer type, or an integer vector type.
<code>N
</code> is
2980 defined by the record position, defining the corresponding value generated by
2981 the instruction.
</p>
2982 <p>The result returned is the mathematical result modulo
2<sup>n
</sup>, where
<code>n
</code>
2983 is the bit width of the integer result.
</p>
2984 <p>Because integers are assumed to use a two
’s complement representation,
2985 this instruction is appropriate for both signed and unsigned integers.
</p>
2986 <p>In the subtract instruction, integer type
<code>i1
</code> (or a vector on integer type
2987 <code>i1
</code>) is disallowed.
</p>
2988 <p><strong>Constraints
</strong>:
</p>
2989 <pre class=
"prettyprint">
2990 AA == AbbrevIndex(A)
&
2991 VV1 == RelativeIndex(V1)
&
2992 VV2 == RelativeIndex(V2)
&
2993 T == TypeOf(V1) == TypeOf(V2)
&
2994 IsInteger(UnderlyingType(T))
&
2995 UnderlyingType(T) != i1
&
2998 <p><strong>Updates
</strong>:
</p>
2999 <pre class=
"prettyprint">
3003 <p><strong>Examples
</strong>:
</p>
3004 <pre class=
"prettyprint">
3005 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
3007 104:
0|
3:
<1,
1> | blocks
1;
3009 106:
4|
3:
<2,
2,
1,
2> | %v0 = mul i32 %p0, %p1;
3010 110:
4|
3:
<2,
1,
3,
2> | %v1 = mul i32 %v0, %p0;
3011 114:
4|
3:
<10,
1> | ret i32 %v1;
3012 117:
0|
0:
<65534> | }
3014 <h3 id=
"signed-integer-divide">Signed Integer Divide
</h3>
3015 <p>The signed integer divide instruction returns the quotient of its two arguments.
3016 Both arguments and the result must be of the same type. That type must be
3017 integer, or an integer vector type.
</p>
3018 <p><strong>Syntax
</strong>:
</p>
3019 <pre class=
"prettyprint">
3020 %vN = sdiv T V1, V2;
<A
>
3022 <p><strong>Record
</strong>:
</p>
3023 <pre class=
"prettyprint">
3024 AA:
<2, VV1, VV2,
4>
3026 <p><strong>Semantics
</strong>:
</p>
3027 <p>The signed integer divide instruction returns the quotient of its two
3028 arguments. Arguments
<code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code>, must be of type
3029 <code>T
</code>.
<code>T
</code> must be a integer type, or an integer vector type.
<code>N
</code> is defined
3030 by the record position, defining the corresponding value generated by the
3032 <p>Signed values are assumed. Note that signed and unsigned integer division are
3033 distinct operations. For unsigned integer division use the unsigned integer
3034 divide instruction (udiv).
</p>
3035 <p>In the signed integer divide instruction, integer type
<code>i1
</code> (and a vector of
3036 integer type
<code>i1
</code>) is disallowed. Integer division by zero is guaranteed to
3038 <p>Note that overflow can happen with this instruction when dividing the maximum
3039 negative integer by
<code>-
1</code>. The behavior for this case is currently undefined.
</p>
3040 <p><strong>Constraints
</strong>:
</p>
3041 <pre class=
"prettyprint">
3042 AA == AbbrevIndex(A)
&
3043 VV1 == RelativeIndex(V1)
&
3044 VV2 == RelativeIndex(V2)
&
3045 T == TypeOf(V1) == TypeOf(V2)
&
3046 IsInteger(UnderlyingType(T))
&
3047 UnderlyingType(T) != i1
&
3050 <p><strong>Updates
</strong>:
</p>
3051 <pre class=
"prettyprint">
3055 <p><strong>Examples
</strong>:
</p>
3056 <pre class=
"prettyprint">
3057 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
3059 104:
0|
3:
<1,
1> | blocks
1;
3061 106:
4|
3:
<2,
2,
1,
4> | %v0 = sdiv i32 %p0, %p1;
3062 110:
4|
3:
<2,
1,
2,
4> | %v1 = sdiv i32 %v0, %p1;
3063 114:
4|
3:
<10,
1> | ret i32 %v1;
3064 117:
0|
0:
<65534> | }
3066 <h3 id=
"unsigned-integer-divide">Unsigned Integer Divide
</h3>
3067 <p>The unsigned integer divide instruction returns the quotient of its two
3068 arguments. Both the arguments and the result must be of the same type. That type
3069 must be integer, or an integer vector type.
</p>
3070 <p><strong>Syntax
</strong>:
</p>
3071 <pre class=
"prettyprint">
3072 %vN = udiv T V1, V2;
<a
>
3074 <p><strong>Record
</strong>:
</p>
3075 <pre class=
"prettyprint">
3076 AA:
<2, A1, A2,
3>
3078 <p><strong>Semantics
</strong>:
</p>
3079 <p>The unsigned integer divide instruction returns the quotient of its two
3080 arguments. Arguments
<code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code>, must be of type
3081 <code>T
</code>.
<code>T
</code> must be an integer type, or an integer vector type.
<code>N
</code> is
3082 defined by the record position, defining the corresponding value generated by
3083 the instruction.
</p>
3084 <p>Unsigned integer values are assumed. Note that signed and unsigned integer
3085 division are distinct operations. For signed integer division use the signed
3086 integer divide instruction (sdiv).
</p>
3087 <p>In the unsigned integer divide instruction, integer type
<code>i1
</code> (and a vector of
3088 integer type
<code>i1
</code>) is disallowed. Division by zero is guaranteed to trap.
</p>
3089 <p><strong>Constraints
</strong>:
</p>
3090 <pre class=
"prettyprint">
3091 AA == AbbrevIndex(A)
&
3092 VV1 == RelativeIndex(V1)
&
3093 VV2 == RelativeIndex(V2)
&
3094 T == TypeOf(V1) == TypeOf(V2)
&
3095 IsInteger(UnderlyingType(T))
&
3096 UnderlyingType(T) != i1
&
3099 <p><strong>Updates
</strong>:
</p>
3100 <pre class=
"prettyprint">
3104 <p><strong>Examples
</strong>:
</p>
3105 <pre class=
"prettyprint">
3106 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
3108 104:
0|
3:
<1,
1> | blocks
1;
3110 106:
4|
3:
<2,
2,
1,
3> | %v0 = udiv i32 %p0, %p1;
3111 110:
4|
3:
<2,
1,
2,
3> | %v1 = udiv i32 %v0, %p1;
3112 114:
4|
3:
<10,
1> | ret i32 %v1;
3113 117:
0|
0:
<65534> | }
3115 <h3 id=
"signed-integer-remainder">Signed Integer Remainder
</h3>
3116 <p>The signed integer remainder instruction returns the remainder of the quotient
3117 of its two arguments. Both arguments and the result must be of the same
3118 type. That type must be integer, or an integer based vector type.
</p>
3119 <p><strong>Syntax
</strong>:
</p>
3120 <pre class=
"prettyprint">
3121 %vN = srem T V1, V2;
<A
>
3123 <p><strong>Record
</strong>:
</p>
3124 <pre class=
"prettyprint">
3125 AA:
<2, VV1, VV2,
6>
3127 <p><strong>Semantics
</strong>:
</p>
3128 <p>The signed integer remainder instruction returns the remainder of the quotient
3129 of its two arguments. Arguments
<code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code>, must
3130 be of type
<code>T
</code>.
<code>T
</code> must be a integer type, or an integer vector type.
<code>N
</code>
3131 is defined by the record position, defining the corresponding value generated by
3132 the instruction.
</p>
3133 <p>Signed values are assumed. Note that signed and unsigned integer division are
3134 distinct operations. For unsigned integer division use the unsigned integer
3135 remainder instruction (urem).
</p>
3136 <p>In the signed integer remainder instruction, integer type
<code>i1
</code> (and a vector
3137 of integer type
<code>i1
</code>) is disallowed. Division by zero is guaranteed to trap.
</p>
3138 <p>Note that overflow can happen with this instruction when dividing the maximum
3139 negative integer by
<code>-
1</code>. The behavior for this case is currently undefined.
</p>
3140 <p><strong>Constraints
</strong>:
</p>
3141 <pre class=
"prettyprint">
3142 AA == AbbrevIndex(A)
&
3143 VV1 == RelativeIndex(V1)
&
3144 VV2 == RelativeIndex(V2)
&
3145 T == TypeOf(V1) == TypeOf(V2)
&
3146 IsInteger(UnderlyingType(T))
&
3147 UnderlyingType(T) != i1
&
3150 <p><strong>Updates
</strong>:
</p>
3151 <pre class=
"prettyprint">
3155 <p><strong>Examples
</strong>:
</p>
3156 <pre class=
"prettyprint">
3157 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
3159 104:
0|
3:
<1,
1> | blocks
1;
3161 106:
4|
3:
<2,
2,
1,
6> | %v0 = srem i32 %p0, %p1;
3162 110:
4|
3:
<2,
1,
2,
6> | %v1 = srem i32 %v0, %p1;
3163 114:
4|
3:
<10,
1> | ret i32 %v1;
3164 117:
0|
0:
<65534> | }
3166 <h3 id=
"unsigned-integer-remainder-instruction">Unsigned Integer Remainder Instruction
</h3>
3167 <p>The unsigned integer remainder instruction returns the remainder of the quotient
3168 of its two arguments. Both the arguments and the result must be of the same
3169 type. The type must be integer, or an integer vector type.
</p>
3170 <p><strong>Syntax
</strong>:
</p>
3171 <pre class=
"prettyprint">
3172 %vN = urem T V1, V2;
<A
>
3174 <p><strong>Record
</strong>:
</p>
3175 <pre class=
"prettyprint">
3176 AA:
<2, A1, A2,
5>
3178 <p><strong>Semantics
</strong>:
</p>
3179 <p>The unsigned integer remainder instruction returns the remainder of the quotient
3180 of its two arguments. Arguments
<code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code>, must
3181 be of type
<code>T
</code>.
<code>T
</code> must be an integer type, or an integer vector type.
3182 <code>N
</code> is defined by the record position, defining the corresponding value
3183 generated by the instruction.
</p>
3184 <p>Unsigned values are assumed. Note that signed and unsigned integer division are
3185 distinct operations. For signed integer division use the remainder instruction
3187 <p>In the unsigned integer remainder instruction, integer type
<code>i1
</code> (and a vector
3188 of integer type
<code>i1
</code>) is disallowed. Division by zero is guaranteed to trap.
</p>
3189 <p><strong>Constraints
</strong>:
</p>
3190 <pre class=
"prettyprint">
3191 AA == AbbrevIndex(A)
&
3192 VV1 == RelativeIndex(V1)
&
3193 VV2 == RelativeIndex(V2)
&
3194 T == TypeOf(V1) == TypeOf(V2)
&
3195 IsInteger(UnderlyingType(T))
&
3196 UnderlyingType(T) != i1
&
3199 <p><strong>Updates
</strong>:
</p>
3200 <pre class=
"prettyprint">
3204 <p><strong>Examples
</strong>:
</p>
3205 <pre class=
"prettyprint">
3206 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
3208 104:
0|
3:
<1,
1> | blocks
1;
3210 106:
4|
3:
<2,
2,
1,
5> | %v0 = urem i32 %p0, %p1;
3211 110:
4|
3:
<2,
1,
2,
5> | %v1 = urem i32 %v0, %p1;
3212 114:
4|
3:
<10,
1> | ret i32 %v1;
3213 117:
0|
0:
<65534> | }
3215 <h3 id=
"shift-left">Shift Left
</h3>
3216 <p>The (integer) shift left instruction returns the first operand, shifted to the
3217 left a specified number of bits with zero fill. The shifted value must be
3218 integer, or an integer vector type.
</p>
3219 <p><strong>Syntax
</strong>:
</p>
3220 <pre class=
"prettyprint">
3221 %vN = shl T V1, V2;
<A
>
3223 <p><strong>Record
</strong>:
</p>
3224 <pre class=
"prettyprint">
3225 AA:
<2, VV1, VV2,
7>
3227 <p><strong>Semantics
</strong>:
</p>
3228 <p>This instruction performs a shift left operation. Arguments
<code>V1
</code> and
<code>V2
</code>
3229 and the result
<code>%vN
</code> must be of type
<code>T
</code>.
<code>T
</code> must be an integer, or a
3230 vector of integers.
<code>N
</code> is defined by the record position, defining the
3231 corresponding value generated by the instruction.
</p>
3232 <p><code>V2
</code> is assumed to be unsigned. The least significant bits of the result will
3233 be filled with zero bits after the shift. If
<code>V2
</code> is (statically or
3234 dynamically) negative or equal to or larger than the number of bits in
3235 <code>V1
</code>, the result is undefined. If the arguments are vectors, each vector
3236 element of
<code>V1
</code> is shifted by the corresponding shift amount in
<code>V2
</code>.
</p>
3237 <p>In the shift left instruction, integer type
<code>i1
</code> (and a vector of integer type
3238 <code>i1
</code>) is disallowed.
</p>
3239 <p><strong>Constraints
</strong>:
</p>
3240 <pre class=
"prettyprint">
3241 AA == AbbrevIndex(A)
&
3242 VV1 == RelativeIndex(V1)
&
3243 VV2 == RelativeIndex(V2)
&
3244 T == TypeOf(V1) == TypeOf(V2)
&
3245 IsInteger(UnderlyingType(T))
&
3246 UnderlyingType(T) != i1
&
3249 <p><strong>Updates
</strong>:
</p>
3250 <pre class=
"prettyprint">
3254 <p><strong>Examples
</strong>:
</p>
3255 <pre class=
"prettyprint">
3256 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
3258 104:
0|
3:
<1,
1> | blocks
1;
3260 106:
4|
3:
<2,
2,
1,
7> | %v0 = shl i32 %p0, %p1;
3261 110:
4|
3:
<2,
1,
2,
7> | %v1 = shl i32 %v0, %p1;
3262 114:
4|
3:
<10,
1> | ret i32 %v1;
3263 117:
0|
0:
<65534> | }
3265 <h3 id=
"logical-shift-right">Logical Shift Right
</h3>
3266 <p>The logical shift right instruction returns the first operand, shifted to the
3267 right a specified number of bits with zero fill.
</p>
3268 <p><strong>Syntax
</strong>:
</p>
3269 <pre class=
"prettyprint">
3270 %vN = lshr T V1, V2;
<A
>
3272 <p><strong>Record
</strong>:
</p>
3273 <pre class=
"prettyprint">
3274 AA:
<2, VV1, VV2,
8>
3276 <p><strong>Semantics
</strong>:
</p>
3277 <p>This instruction performs a logical shift right operation. Arguments
<code>V1
</code> and
3278 <code>V2
</code> and the result
<code>%vN
</code> must be of type
<code>T
</code>.
<code>T
</code> must be an integer,
3279 or a vector of integers.
<code>N
</code> is defined by the record position, defining the
3280 corresponding value generated by the instruction.
</p>
3281 <p><code>V2
</code> is assumed to be unsigned. The most significant bits of the result will
3282 be filled with zero bits after the shift. If
<code>V2
</code> is (statically or
3283 dynamically) negative or equal to or larger than the number of bits in
<code>V1
</code>,
3284 the result is undefined. If the arguments are vectors, each vector element of
3285 <code>V1
</code> is shifted by the corresponding shift amount in
<code>V2
</code>.
</p>
3286 <p>In the logical shift right instruction, integer type
<code>i1
</code> (and a vector of
3287 integer type
<code>i1
</code>) is disallowed.
</p>
3288 <p><strong>Constraints
</strong>:
</p>
3289 <pre class=
"prettyprint">
3290 AA == AbbrevIndex(A)
&
3291 VV1 == RelativeIndex(V1)
&
3292 VV2 == RelativeIndex(V2)
&
3293 T == TypeOf(V1) == TypeOf(V2)
&
3294 IsInteger(UnderlyingType(T))
&
3295 UnderlyingType(T) != i1
&
3298 <p><strong>Updates
</strong>:
</p>
3299 <pre class=
"prettyprint">
3303 <p><strong>Examples
</strong>:
</p>
3304 <pre class=
"prettyprint">
3305 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
3307 104:
0|
3:
<1,
1> | blocks
1;
3309 106:
4|
3:
<2,
2,
1,
8> | %v0 = lshr i32 %p0, %p1;
3310 110:
4|
3:
<2,
1,
2,
8> | %v1 = lshr i32 %v0, %p1;
3311 114:
4|
3:
<10,
1> | ret i32 %v1;
3312 117:
0|
0:
<65534> | }
3314 <h3 id=
"arithmetic-shift-right">Arithmetic Shift Right
</h3>
3315 <p>The arithmetic shift right instruction returns the first operand, shifted to the
3316 right a specified number of bits with sign extension.
</p>
3317 <p><strong>Syntax
</strong>:
</p>
3318 <pre class=
"prettyprint">
3319 %vN = ashr T V1, V2;
<A
>
3321 <p><strong>Record
</strong>:
</p>
3322 <pre class=
"prettyprint">
3323 AA:
<2, VV1, VVA2,
9>
3325 <p><strong>Semantics
</strong>:
</p>
3326 <p>This instruction performs an arithmetic shift right operation. Arguments
<code>V1
</code>
3327 and
<code>V2
</code> and and the result
<code>%vN
</code> must be of type
<code>T
</code>.
<code>T
</code> must be an
3328 integer, or a vector of integers.
<code>N
</code> is defined by the record position,
3329 defining the corresponding value generated by the instruction.
</p>
3330 <p><code>V2
</code> is assumed to be unsigned. The most significant bits of the result will
3331 be filled with the sign bit of
<code>V1
</code>. If
<code>V2
</code> is (statically or dynamically)
3332 negative or equal to or larger than the number of bits in
<code>V1
</code>, the result is
3333 undefined. If the arguments are vectors, each vector element of
<code>V1
</code> is
3334 shifted by the corresponding shift amount in
<code>V2
</code>.
</p>
3335 <p>In the arithmetic shift right instruction, integer type
<code>i1
</code> (and a vector of
3336 integral type
<code>i1
</code>) is disallowed.
</p>
3337 <p><strong>Constraints
</strong>:
</p>
3338 <pre class=
"prettyprint">
3339 AA == AbbrevIndex(A)
&
3340 VV1 == RelativeIndex(V1)
&
3341 VV2 == RelativeIndex(V2)
&
3342 T == TypeOf(V1) == TypeOf(V2)
&
3343 IsInteger(UnderlyingType(T))
&
3344 UnderlyingType(T) != i1
&
3347 <p><strong>Updates
</strong>:
</p>
3348 <pre class=
"prettyprint">
3352 <p><strong>Examples
</strong>:
</p>
3353 <pre class=
"prettyprint">
3354 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
3356 104:
0|
3:
<1,
1> | blocks
1;
3358 106:
4|
3:
<2,
2,
1,
9> | %v0 = ashr i32 %p0, %p1;
3359 110:
4|
3:
<2,
1,
2,
9> | %v1 = ashr i32 %v0, %p1;
3360 114:
4|
3:
<10,
1> | ret i32 %v1;
3361 117:
0|
0:
<65534> | }
3363 <h3 id=
"logical-and">Logical And
</h3>
3364 <p>The
<em>and
</em> instruction returns the bitwise logical and of its two operands.
</p>
3365 <p><strong>Syntax
</strong>:
</p>
3366 <pre class=
"prettyprint">
3367 %vN = and T V1, V2;
<A
>
3369 <p><strong>Record
</strong>:
</p>
3370 <pre class=
"prettyprint">
3371 AA:
<2, VV1, VV2,
10>
3373 <p><strong>Semantics
</strong>:
</p>
3374 <p>This instruction performs a bitwise logical and of its arguments. Arguments
3375 <code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code> must be of type
<code>T
</code>.
<code>T
</code> must be
3376 an integer, or a vector of integers.
<code>N
</code> is defined by the record position,
3377 defining the corresponding value generated by the instruction.
<code>A
</code> is the
3378 (optional) abbreviation associated with the corresponding record.
</p>
3379 <p>The truth table used for the
<em>and
</em> instruction is:
</p>
3380 <table border=
"1" class=
"docutils">
3383 <thead valign=
"bottom">
3384 <tr class=
"row-odd"><th class=
"head">Arg
1</th>
3385 <th class=
"head">Arg
2</th>
3386 <th class=
"head">Result
</th>
3389 <tbody valign=
"top">
3390 <tr class=
"row-even"><td>0</td>
3394 <tr class=
"row-odd"><td>0</td>
3398 <tr class=
"row-even"><td>1</td>
3402 <tr class=
"row-odd"><td>1</td>
3408 <p><strong>Constraints
</strong>:
</p>
3409 <pre class=
"prettyprint">
3410 AA == AbbrevIndex(A)
&
3411 VV1 == RelativeIndex(V1)
&
3412 VV2 == RelativeIndex(V2)
&
3413 T == TypeOf(V1) == TypeOf(V2)
&
3414 IsInteger(UnderlyingType(T)))
&
3417 <p><strong>Updates
</strong>:
</p>
3418 <pre class=
"prettyprint">
3422 <p><strong>Examples
</strong>:
</p>
3423 <pre class=
"prettyprint">
3424 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
3426 104:
0|
3:
<1,
1> | blocks
1;
3428 106:
4|
3:
<2,
2,
1,
10> | %v0 = and i32 %p0, %p1;
3429 110:
4|
3:
<2,
1,
2,
10> | %v1 = and i32 %v0, %p1;
3430 114:
4|
3:
<10,
1> | ret i32 %v1;
3431 117:
0|
0:
<65534> | }
3433 <h3 id=
"logical-or">Logical Or
</h3>
3434 <p>The
<em>or
</em> instruction returns the bitwise logical inclusive or of its
3436 <p><strong>Syntax
</strong>:
</p>
3437 <pre class=
"prettyprint">
3438 %vN = or T V1, V2;
<A
>
3440 <p><strong>Record
</strong>:
</p>
3441 <pre class=
"prettyprint">
3442 AA:
<2, VV1, VV2,
11>
3444 <p><strong>Semantics
</strong>:
</p>
3445 <p>This instruction performs a bitwise logical inclusive or of its arguments.
3446 Arguments
<code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code> must be of type
<code>T
</code>.
<code>T
</code>
3447 must be an integer, or a vector of integers.
<code>N
</code> is defined by the record
3448 position, defining the corresponding value generated by the instruction.
</p>
3449 <p>The truth table used for the
<em>or
</em> instruction is:
</p>
3450 <table border=
"1" class=
"docutils">
3453 <thead valign=
"bottom">
3454 <tr class=
"row-odd"><th class=
"head">Arg
1</th>
3455 <th class=
"head">Arg
2</th>
3456 <th class=
"head">Result
</th>
3459 <tbody valign=
"top">
3460 <tr class=
"row-even"><td>0</td>
3464 <tr class=
"row-odd"><td>0</td>
3468 <tr class=
"row-even"><td>1</td>
3472 <tr class=
"row-odd"><td>1</td>
3478 <p><strong>Constraints
</strong>:
</p>
3479 <pre class=
"prettyprint">
3480 AA == AbbrevIndex(A)
&
3481 VV1 == RelativeIndex(V1)
&
3482 VV2 == RelativeIndex(V2)
&
3483 T == TypeOf(V1) == TypeOf(V2)
&
3484 IsInteger(UnderlyingType(T)))
&
3487 <p><strong>Updates
</strong>:
</p>
3488 <pre class=
"prettyprint">
3492 <p><strong>Examples
</strong>:
</p>
3493 <pre class=
"prettyprint">
3494 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
3496 104:
0|
3:
<1,
1> | blocks
1;
3498 106:
4|
3:
<2,
2,
1,
11> | %v0 = or i32 %p0, %p1;
3499 110:
4|
3:
<2,
1,
2,
11> | %v1 = or i32 %v0, %p1;
3500 114:
4|
3:
<10,
1> | ret i32 %v1;
3501 117:
0|
0:
<65534> | }
3503 <h3 id=
"logical-xor">Logical Xor
</h3>
3504 <p>The
<em>xor
</em> instruction returns the bitwise logical exclusive or of its
3506 <p><strong>Syntax
</strong>:
</p>
3507 <pre class=
"prettyprint">
3508 %vN = xor T V1, V2;
<A
>
3510 <p><strong>Record
</strong>:
</p>
3511 <pre class=
"prettyprint">
3512 AA:
<2, VV1, VV2,
12>
3514 <p><strong>Semantics
</strong>:
</p>
3515 <p>This instruction performs a bitwise logical exclusive or of its arguments.
3516 Arguments
<code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code> must be of type
<code>T
</code>.
<code>T
</code>
3517 must be an integer, or a vector of integers.
<code>N
</code> is defined by the record
3518 position, defining the corresponding value generated by the instruction.
</p>
3519 <p>The truth table used for the
<em>xor
</em> instruction is:
</p>
3520 <table border=
"1" class=
"docutils">
3523 <thead valign=
"bottom">
3524 <tr class=
"row-odd"><th class=
"head">Arg
1</th>
3525 <th class=
"head">Arg
2</th>
3526 <th class=
"head">Result
</th>
3529 <tbody valign=
"top">
3530 <tr class=
"row-even"><td>0</td>
3534 <tr class=
"row-odd"><td>0</td>
3538 <tr class=
"row-even"><td>1</td>
3542 <tr class=
"row-odd"><td>1</td>
3548 <p><strong>Constraints
</strong>:
</p>
3549 <pre class=
"prettyprint">
3550 AA == AbbrevIndex(A)
&
3551 A1 == RelativeIndex(V1)
&
3552 A2 == RelativeIndex(V2)
&
3553 T == TypeOf(V1) == TypeOf(V2)
&
3554 IsInteger(UnderlyingType(T)))
&
3557 <p><strong>Updates
</strong>:
</p>
3558 <pre class=
"prettyprint">
3562 <p><strong>Examples
</strong>:
</p>
3563 <pre class=
"prettyprint">
3564 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
3566 104:
0|
3:
<1,
1> | blocks
1;
3568 106:
4|
3:
<2,
2,
1,
12> | %v0 = xor i32 %p0, %p1;
3569 110:
4|
3:
<2,
1,
2,
12> | %v1 = xor i32 %v0, %p1;
3570 114:
4|
3:
<10,
1> | ret i32 %v1;
3571 117:
0|
0:
<65534> | }
3573 <h2 id=
"floating-point-binary-instructions"><span id=
"link-for-floating-point-binary-instructions"></span>Floating Point Binary Instructions
</h2>
3574 <p>Floating point binary instructions require two operands of the same type,
3575 execute an operation on them, and produce a value. The value may represent
3576 multiple values if the type is a vector type. The result value always has the
3577 same type as its operands.
</p>
3578 <h3 id=
"floating-point-add">Floating Point Add
</h3>
3579 <p>The floating point add instruction returns the sum of its two arguments. Both
3580 arguments and the result must be of the same type. That type must be a floating
3581 point type, or a vector of a floating point type.
</p>
3582 <p><strong>Syntax
</strong>:
</p>
3583 <pre class=
"prettyprint">
3584 %vN = fadd T V1, V2;
<A
>
3586 <p><strong>Record
</strong>:
</p>
3587 <pre class=
"prettyprint">
3588 AA:
<2, VV1, VV2,
0>
3590 <p><strong>Semantics
</strong>:
</p>
3591 <p>The floating point add instruction returns the sum of its two arguments.
3592 Arguments
<code>V1
</code> and
<code>V2
</code> and the result
<code>%vN
</code> must be of type
<code>T
</code>.
<code>T
</code>
3593 must be a floating point type, or a vector of a floating point type.
<code>N
</code> is
3594 defined by the record position, defining the corresponding value generated by
3595 the instruction.
</p>
3596 <p><strong>Constraints
</strong>:
</p>
3597 <pre class=
"prettyprint">
3598 AA == AbbrevIndex(A)
&
3599 VV1 == RelativeIndex(V1)
&
3600 VV2 == RelativeIndex(V2)
&
3601 T == TypeOf(V1) == TypeOf(V2)
&
3602 IsFloat(UnderlyingType(T))
&
3605 <p><strong>Updates
</strong>:
</p>
3606 <pre class=
"prettyprint">
3610 <p><strong>Examples
</strong>:
</p>
3611 <pre class=
"prettyprint">
3612 92:
0|
1:
<65535,
12,
2> | function
3613 | | float
@f0(float %p0, float %p1) {
3615 100:
0|
3:
<1,
1> | blocks
1;
3617 102:
4|
3:
<2,
2,
1,
0> | %v0 = fadd float %p0, %p1;
3618 106:
4|
3:
<2,
3,
1,
0> | %v1 = fadd float %p0, %v0;
3619 110:
4|
3:
<10,
1> | ret float %v1;
3620 113:
0|
0:
<65534> | }
3622 <h3 id=
"floating-point-subtract">Floating Point Subtract
</h3>
3623 <p>The floating point subtract instruction returns the difference of its two
3624 arguments. Both arguments and the result must be of the same type. That type
3625 must be a floating point type, or a vector of a floating point type.
</p>
3626 <p><strong>Syntax
</strong>:
</p>
3627 <pre class=
"prettyprint">
3628 %vN = fsub T V1, V2;
<a
>
3630 <p><strong>Record
</strong>:
</p>
3631 <pre class=
"prettyprint">
3632 AA:
<2, VV1, VV2,
1>
3634 <p><strong>Semantics
</strong>:
</p>
3635 <p>The floating point subtract instruction returns the difference of its two
3636 arguments. Arguments
<code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code> must be of type
3637 <code>T
</code>.
<code>T
</code> must be a floating point type, or a vector of a floating point
3638 type.
<code>N
</code> is defined by the record position, defining the corresponding value
3639 generated by the instruction.
</p>
3640 <p><strong>Constraints
</strong>:
</p>
3641 <pre class=
"prettyprint">
3642 AA == AbbrevIndex(A)
&
3643 VV1 == RelativeIndex(V1)
&
3644 VV2 == RelativeIndex(V2)
&
3645 T == TypeOf(V1) == TypeOf(V2)
&
3646 IsFloat(UnderlyingType(T))
&
3649 <p><strong>Updates
</strong>:
</p>
3650 <pre class=
"prettyprint">
3654 <p><strong>Examples
</strong>:
</p>
3655 <pre class=
"prettyprint">
3656 92:
0|
1:
<65535,
12,
2> | function
3657 | | float
@f0(float %p0, float %p1) {
3659 100:
0|
3:
<1,
1> | blocks
1;
3661 102:
4|
3:
<2,
2,
1,
1> | %v0 = fsub float %p0, %p1;
3662 106:
4|
3:
<2,
3,
1,
1> | %v1 = fsub float %p0, %v0;
3663 110:
4|
3:
<10,
1> | ret float %v1;
3664 113:
0|
0:
<65534> | }
3666 <h3 id=
"floating-point-multiply">Floating Point Multiply
</h3>
3667 <p>The floating point multiply instruction returns the product of its two
3668 arguments. Both arguments and the result must be of the same type. That type
3669 must be a floating point type, or a vector of a floating point type.
</p>
3670 <p><strong>Syntax
</strong>:
</p>
3671 <pre class=
"prettyprint">
3672 &vN = fmul T V1, V2;
<A
>
3674 <p><strong>Record
</strong>:
</p>
3675 <pre class=
"prettyprint">
3676 AA:
<2, VV1, VV2,
2>
3678 <p><strong>Semantics
</strong>:
</p>
3679 <p>The floating point multiply instruction returns the product of its two
3680 arguments. Arguments
<code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code> must be of type
3681 <code>T
</code>.
<code>T
</code> must be a floating point type, or a vector of a floating point
3682 type.
<code>N
</code> is defined by the record position, defining the corresponding value
3683 generated by the instruction.
</p>
3684 <p><strong>Constraints
</strong>:
</p>
3685 <pre class=
"prettyprint">
3686 AA == AbbrevIndex(A)
&
3687 VV1 == RelativeIndex(V1)
&
3688 VV2 == RelativeIndex(V2)
&
3689 T == TypeOf(V1) == TypeOf(V2)
&
3690 IsFloat(UnderlyingType(T))
&
3693 <p><strong>Updates
</strong>:
</p>
3694 <pre class=
"prettyprint">
3698 <p><strong>Examples
</strong>:
</p>
3699 <pre class=
"prettyprint">
3700 92:
0|
1:
<65535,
12,
2> | function
3701 | | float
@f0(float %p0, float %p1) {
3703 100:
0|
3:
<1,
1> | blocks
1;
3705 102:
4|
3:
<2,
2,
1,
2> | %v0 = fmul float %p0, %p1;
3706 106:
4|
3:
<2,
3,
1,
2> | %v1 = fmul float %p0, %v0;
3707 110:
4|
3:
<10,
1> | ret float %v1;
3708 113:
0|
0:
<65534> | }
3710 <h3 id=
"floating-point-divide">Floating Point Divide
</h3>
3711 <p>The floating point divide instruction returns the quotient of its two
3712 arguments. Both arguments and the result must be of the same type. That type
3713 must be a floating point type, or a vector of a floating point type.
</p>
3714 <p><strong>Syntax
</strong>:
</p>
3715 <pre class=
"prettyprint">
3716 %vN = fdiv T V1, V2;
<A
>
3718 <p><strong>Record
</strong>:
</p>
3719 <pre class=
"prettyprint">
3720 AA:
<2, V1, V2,
4>
3722 <p><strong>Semantics
</strong>:
</p>
3723 <p>The floating point divide instruction returns the quotient of its two
3724 arguments. Arguments
<code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code> must be of type
3725 <code>T
</code>.
<code>T
</code> must be a floating point type, or a vector of a floating point
3726 type.
<code>N
</code> is defined by the record position, defining the corresponding value
3727 generated by the instruction.
</p>
3728 <p><strong>Constraints
</strong>:
</p>
3729 <pre class=
"prettyprint">
3730 AA == AbbrevIndex(A)
&
3731 VV1 == RelativeIndex(V1)
&
3732 VV22 == RelativeIndex(V2)
&
3733 T == TypeOf(V1) == TypeOf(V2)
&
3734 IsFloat(UnderlyingType(T))
&
3737 <p><strong>Updates
</strong>:
</p>
3738 <pre class=
"prettyprint">
3742 <p><strong>Examples
</strong>:
</p>
3743 <pre class=
"prettyprint">
3744 92:
0|
1:
<65535,
12,
2> | function
3746 | |
@f0(double %p0, double %p1) {
3748 100:
0|
3:
<1,
1> | blocks
1;
3750 102:
4|
3:
<2,
2,
1,
4> | %v0 = fdiv double %p0, %p1;
3751 106:
4|
3:
<2,
3,
1,
4> | %v1 = fdiv double %p0, %v0;
3752 110:
4|
3:
<10,
1> | ret double %v1;
3753 113:
0|
0:
<65534> | }
3755 <h3 id=
"floating-point-remainder">Floating Point Remainder
</h3>
3756 <p>The floating point remainder instruction returns the remainder of the quotient
3757 of its two arguments. Both arguments and the result must be of the same
3758 type. That type must be a floating point type, or a vector of a floating point
3760 <p><strong>Syntax
</strong>:
</p>
3761 <pre class=
"prettyprint">
3762 %vN = frem T V1, V2;
<A
>
3764 <p><strong>Record
</strong>:
</p>
3765 <pre class=
"prettyprint">
3766 AA:
<2, VV1, VV2,
6>
3768 <p><strong>Semantics
</strong>:
</p>
3769 <p>The floating point remainder instruction returns the remainder of the quotient
3770 of its two arguments. Arguments
<code>V1
</code> and
<code>V2
</code>, and the result
<code>%vN
</code> must
3771 be of type
<code>T
</code>.
<code>T
</code> must be a floating point type, or a vector of a floating
3772 point type.
<code>N
</code> is defined by the record position, defining the corresponding
3773 value generated by the instruction.
</p>
3774 <p><strong>Constraints
</strong>:
</p>
3775 <pre class=
"prettyprint">
3776 AA == AbbrevIndex(A)
&
3777 VV1 == RelativeIndex(V1)
&
3778 VV2 == RelativeIndex(V2)
&
3779 T == TypeOf(V1) == TypeOf(V2)
&
3780 IsFloat(UnderlyingType(T))
&
3783 <p><strong>Updates
</strong>:
</p>
3784 <pre class=
"prettyprint">
3788 <p><strong>Examples
</strong>:
</p>
3789 <pre class=
"prettyprint">
3790 92:
0|
1:
<65535,
12,
2> | function
3792 | |
@f0(double %p0, double %p1) {
3794 100:
0|
3:
<1,
1> | blocks
1;
3796 102:
4|
3:
<2,
2,
1,
6> | %v0 = frem double %p0, %p1;
3797 106:
4|
3:
<2,
3,
1,
6> | %v1 = frem double %p0, %v0;
3798 110:
4|
3:
<10,
1> | ret double %v1;
3799 113:
0|
0:
<65534> | }
3801 <h2 id=
"memory-creation-and-access-instructions"><span id=
"link-for-memory-creation-and-access-instructions"></span>Memory Creation and Access Instructions
</h2>
3802 <p>A key design point of SSA-based representation is how it represents
3803 memory. In PNaCl bitcode files, no memory locations are in SSA
3804 form. This makes things very simple.
</p>
3805 <h3 id=
"alloca-instruction"><span id=
"link-for-alloca-instruction"></span>Alloca Instruction
</h3>
3806 <p>The
<em>alloca
</em> instruction allocates memory on the stack frame of the
3807 currently executing function. This memory is automatically released
3808 when the function returns to its caller.
</p>
3809 <p><strong>Syntax
</strong>:
</p>
3810 <pre class=
"prettyprint">
3811 %vN = alloca i8, i32 S, align V;
<A
>
3813 <p><strong>Record
</strong>:
</p>
3814 <pre class=
"prettyprint">
3815 AA:
<19, SS, VV
>
3817 <p><strong>Semantics
</strong>:
</p>
3818 <p>The
<em>alloca
</em> instruction allocates memory on the stack frame of the currently
3819 executing function. The resulting value is a pointer to the allocated memory
3820 (i.e. of type i32).
<code>S
</code> is the number of bytes that are allocated on the
3821 stack.
<code>S
</code> must be of integer type i32.
<code>V
</code> is the alignment of the
3822 generated stack address.
</p>
3823 <p>Alignment must be a power of
2. See
<a class=
"reference internal" href=
"#link-for-memory-blocks-and-alignment-section"><em>memory blocks and
3824 alignment
</em></a> for a more detailed
3825 discussion on how to define alignment.
</p>
3826 <p><strong>Constraints
</strong>:
</p>
3827 <pre class=
"prettyprint">
3828 AA == AbbrevIndex(A)
&
3829 VV == Log2(V+
1)
&
3830 SS == RelativeIndex(S)
&
3831 i32 == TypeOf(S)
&
3834 <p><strong>Updates
</strong>:
</p>
3835 <pre class=
"prettyprint">
3839 <p><strong>Examples
</strong>:
</p>
3840 <pre class=
"prettyprint">
3841 112:
0|
1:
<65535,
12,
2> | function void
@f1() {
3843 120:
0|
3:
<1,
1> | blocks
1;
3844 122:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
3845 132:
0|
3:
<1,
0> | i32:
3846 134:
4|
3:
<4,
4> | %c0 = i32
2;
3847 137:
0|
3:
<4,
8> | %c1 = i32
4;
3848 139:
4|
3:
<4,
16> | %c2 = i32
8;
3849 142:
0|
0:
<65534> | }
3851 144:
0|
3:
<19,
3,
1> | %v0 = alloca i8, i32 %c0, align
1;
3852 147:
2|
3:
<19,
3,
3> | %v1 = alloca i8, i32 %c1, align
4;
3853 150:
4|
3:
<19,
3,
4> | %v2 = alloca i8, i32 %c2, align
8;
3854 153:
6|
3:
<10> | ret void;
3855 155:
4|
0:
<65534> | }
3857 <h3 id=
"load-instruction">Load Instruction
</h3>
3858 <p>The
<em>load
</em> instruction is used to read from memory.
</p>
3859 <p><strong>Syntax
</strong>:
</p>
3860 <pre class=
"prettyprint">
3861 %vN = load T* P, align V;
<A
>
3863 <p><strong>Record
</strong>:
</p>
3864 <pre class=
"prettyprint">
3865 AA:
<20, PP, VV, TT
>
3867 <p><strong>Semantics
</strong>:
</p>
3868 <p>The load instruction is used to read from memory.
<code>P
</code> is the identifier of the
3869 memory address to read. The type of
<code>P
</code> must be an
<code>i32
</code>.
<code>T
</code> is the type
3870 of value to read.
<code>V
</code> is the alignment of the memory address.
</p>
3871 <p>Type
<code>T
</code> must be a vector, integer, or floating point type. Both
<code>float
</code> and
3872 <code>double
</code> types are allowed for floating point types. All integer types except
3874 <p>Alignment must be a power of
2. See
<a class=
"reference internal" href=
"#link-for-memory-blocks-and-alignment-section"><em>memory blocks and
3875 alignment
</em></a> for a more detailed
3876 discussion on how to define alignment.
</p>
3877 <p><strong>Constraints
</strong>:
</p>
3878 <pre class=
"prettyprint">
3879 AA == AbbrevIndex(A)
&
3880 i32 == TypeOf(P)
&
3881 PP == RelativeIndex(P)
&
3882 VV == Log2(V+
1)
&
3883 %tTT == TypeID(T)
&
3886 <p><strong>Updates
</strong>:
</p>
3887 <pre class=
"prettyprint">
3891 <p><strong>Examples
</strong>:
</p>
3892 <pre class=
"prettyprint">
3893 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
3894 48:
0|
3:
<1,
4> | count
4;
3895 50:
4|
3:
<7,
32> |
@t0 = i32;
3896 53:
6|
3:
<2> |
@t1 = void;
3897 55:
4|
3:
<4> |
@t2 = double;
3898 57:
2|
3:
<21,
0,
1,
0> |
@t3 = void (i32);
3899 61:
2|
0:
<65534> | }
3901 96:
0|
1:
<65535,
12,
2> | function void
@f0(i32 %p0) {
3903 104:
0|
3:
<1,
1> | blocks
1;
3905 106:
4|
3:
<20,
1,
1,
0> | %v0 = load i32* %p0, align
1;
3906 110:
4|
3:
<20,
1,
4,
2> | %v1 = load double* %v0, align
8;
3907 114:
4|
3:
<10> | ret void;
3908 116:
2|
0:
<65534> | }
3910 <h3 id=
"store-instruction">Store Instruction
</h3>
3911 <p>The
<em>store
</em> instruction is used to write to memory.
</p>
3912 <p><strong>Syntax
</strong>:
</p>
3913 <pre class=
"prettyprint">
3914 store T S, T* P, align V;
<A
>
3916 <p><strong>Record
</strong>:
</p>
3917 <pre class=
"prettyprint">
3918 AA:
<24, PP, SS, VV
>
3920 <p><strong>Semantics
</strong>:
</p>
3921 <p>The store instruction is used to write to memory.
<code>P
</code> is the identifier of the
3922 memory address to write to. The type of
<code>P
</code> must be an i32 integer.
<code>T
</code> is
3923 the type of value to store.
<code>S
</code> is the value to store, and must be of type
3924 <code>T
</code>.
<code>V
</code> is the alignment of the memory address.
<code>A
</code> is the (optional)
3925 abbreviation index associated with the record.
</p>
3926 <p>Type
<code>T
</code> must be an integer or floating point type. Both
<code>float
</code> and
3927 <code>double
</code> types are allowed for floating point types. All integer types except
3929 <p>Alignment must be a power of
2. See
<a class=
"reference internal" href=
"#link-for-memory-blocks-and-alignment-section"><em>memory blocks and
3930 alignment
</em></a> for a more detailed
3931 discussion on how to define alignment.
</p>
3932 <p><strong>Constraints
</strong>:
</p>
3933 <pre class=
"prettyprint">
3934 AA == AbbrevIndex(A)
&
3935 i32 == TypeOf(P)
&
3936 PP == RelativeIndex(P)
&
3939 <p><strong>Examples
</strong>:
</p>
3940 <pre class=
"prettyprint">
3941 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
3942 48:
0|
3:
<1,
4> | count
4;
3943 50:
4|
3:
<7,
32> |
@t0 = i32;
3944 53:
6|
3:
<2> |
@t1 = void;
3945 55:
4|
3:
<4> |
@t2 = double;
3946 57:
2|
3:
<21,
0,
1,
0,
0,
0,
2>|
@t3 = void (i32, i32, i32, double);
3947 63:
4|
0:
<65534> | }
3949 96:
0|
1:
<65535,
12,
2> | function
3951 | |
@f0(i32 %p0, i32 %p1, i32 %p2,
3954 104:
0|
3:
<1,
1> | blocks
1;
3956 106:
4|
3:
<24,
4,
3,
1> | store i32 %p1, i32* %p0, align
1;
3957 110:
4|
3:
<24,
2,
1,
4> | store double %p3, double* %p2,
3959 114:
4|
3:
<10> | ret void;
3960 116:
2|
0:
<65534> | }
3962 <h2 id=
"conversion-instructions"><span id=
"link-for-conversion-instructions"></span>Conversion Instructions
</h2>
3963 <p>Conversion instructions all take a single operand and a type. The value is
3964 converted to the corresponding type.
</p>
3965 <h3 id=
"integer-truncating-instruction">Integer Truncating Instruction
</h3>
3966 <p>The integer truncating instruction takes a value to truncate, and a type
3967 defining the truncated type. Both types must be integer types, or integer
3968 vectors with the same number of elements. The bit size of the value must be
3969 larger than the bit size of the destination type. Equal sized types are not
3971 <p><strong>Syntax
</strong>:
</p>
3972 <pre class=
"prettyprint">
3973 %vN = trunc T1 V to T2;
<A
>
3975 <p><strong>Record
</strong>:
</p>
3976 <pre class=
"prettyprint">
3977 AA:
<3, VV, TT2,
0>
3979 <p><strong>Semantics
</strong>:
</p>
3980 <p>The integer truncating instruction takes a value
<code>V
</code>, and truncates to type
3981 <code>T2
</code>. Both
<code>T1
</code> and
<code>T2
</code> must be integer types, or integer vectors with
3982 the same number of elements.
<code>T1
</code> has to be wider than
<code>T2
</code>. If the value
3983 doesn
’t fit in in
<code>T2
</code>, then the higher order bits are dropped.
</p>
3984 <p><strong>Constraints
</strong>:
</p>
3985 <pre class=
"prettyprint">
3986 AA == AbbrevIndex(A)
&
3987 TypeOf(V) == T1
&
3988 VV == RelativeIndex(V)
&
3989 %tTT2 == TypeID(T2)
&
3990 BitSizeOf(UnderlyingType(T1))
> BitSizeOf(UnderlyingType(T2))
&
3991 UnderlyingCount(T1) == UnderlyingCount(T2)
&
3992 IsInteger(UnderlyingType(T1))
&
3993 IsInteger(UnderlyingType(T2))
&
3996 <p><strong>Updates
</strong>:
</p>
3997 <pre class=
"prettyprint">
4001 <p><strong>Examples
</strong>:
</p>
4002 <pre class=
"prettyprint">
4003 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4004 48:
0|
3:
<1,
5> | count
5;
4005 50:
4|
3:
<7,
32> |
@t0 = i32;
4006 53:
6|
3:
<2> |
@t1 = void;
4007 55:
4|
3:
<7,
16> |
@t2 = i16;
4008 58:
0|
3:
<21,
0,
1,
0> |
@t3 = void (i32);
4009 62:
0|
3:
<7,
8> |
@t4 = i8;
4010 64:
4|
0:
<65534> | }
4012 100:
0|
1:
<65535,
12,
2> | function void
@f0(i32 %p0) {
4014 108:
0|
3:
<1,
1> | blocks
1;
4016 110:
4|
3:
<3,
1,
2,
0> | %v0 = trunc i32 %p0 to i16;
4017 114:
4|
3:
<3,
1,
4,
0> | %v1 = trunc i16 %v0 to i8;
4018 118:
4|
3:
<10> | ret void;
4019 120:
2|
0:
<65534> | }
4021 <h3 id=
"floating-point-truncating-instruction">Floating Point Truncating Instruction
</h3>
4022 <p>The floating point truncating instruction takes a value to truncate, and a type
4023 defining the truncated type. Both types must be floating point types, or
4024 floating point vectors with the same number of elements. The source must be
4025 <code>double
</code> while the destination is
<code>float
</code>. If the source is a vector, the
4026 destination must also be vector with the same size as the source.
</p>
4027 <p><strong>Syntax
</strong>:
</p>
4028 <pre class=
"prettyprint">
4029 %vN = fptrunc T1 V to T2;
<A
>
4031 <p><strong>Record
</strong>:
</p>
4032 <pre class=
"prettyprint">
4033 AA:
<3, VV, TT2,
7>
4035 <p><strong>Semantics
</strong></p>
4036 <p>The floating point truncating instruction takes a value
<code>V
</code>, and truncates to
4037 type
<code>T2
</code>. Both
<code>T1
</code> and
<code>T2
</code> must be floating point types, or floating
4038 point vectors with the same number of elements.
<code>T1
</code> must be defined on
4039 <code>double
</code> while
<code>T2
</code> is defined on
<code>float
</code>. If the value can
’t fit within
4040 the destination type
<code>T2
</code>, the results are undefined.
</p>
4041 <p><strong>Constraints
</strong>:
</p>
4042 <pre class=
"prettyprint">
4043 TypeOf(V) == T1
&
4044 double == UnderlyingType(T1)
&
4045 float == UnderlyingType(T2)
&
4046 VV == RelativeIndex(V)
&
4047 %tTT2 == TypeID(T2)
&
4048 BitSizeOf(UnderlyingType(T1))
> BitSizeOf(UnderlyingType(T2))
&
4049 UnderlyingCount(T1) == UnderlyingCount(T2)
&
4050 IsFloat(UnderlyingType(T1))
&
4051 IsFloat(UnderlyingType(T2))
&
4054 <p><strong>Updates
</strong>:
</p>
4055 <pre class=
"prettyprint">
4059 <p><strong>Examples
</strong>:
</p>
4060 <pre class=
"prettyprint">
4061 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4062 48:
0|
3:
<1,
4> | count
4;
4063 50:
4|
3:
<3> |
@t0 = float;
4064 52:
2|
3:
<4> |
@t1 = double;
4065 54:
0|
3:
<21,
0,
0,
1> |
@t2 = float (double);
4066 58:
0|
3:
<2> |
@t3 = void;
4067 59:
6|
0:
<65534> | }
4069 92:
0|
1:
<65535,
12,
2> | function float
@f0(double %p0) {
4071 100:
0|
3:
<1,
1> | blocks
1;
4073 102:
4|
3:
<3,
1,
0,
7> | %v0 = fptrunc double %p0 to float;
4074 106:
4|
3:
<10,
1> | ret float %v0;
4075 109:
0|
0:
<65534> | }
4077 <h3 id=
"zero-extending-instruction">Zero Extending Instruction
</h3>
4078 <p>The zero extending instruction takes a value to extend, and a type to extend it
4079 to. Both types must be integer types, or integer vectors with the same number
4080 of elements. The bit size of the source type must be smaller than the bit size
4081 of the destination type. Equal sized types are not allowed.
</p>
4082 <p><strong>Syntax
</strong>:
</p>
4083 <pre class=
"prettyprint">
4084 %vN = zext T1 V to T2;
<A
>
4086 <p><strong>Record
</strong>:
</p>
4087 <pre class=
"prettyprint">
4088 AA:
<3, VV, TT2,
1>
4090 <p><strong>Semantics
</strong>:
</p>
4091 <p>The zero extending instruction takes a value
<code>V
</code>, and expands it to type
4092 <code>T2
</code>. Both
<code>T1
</code> and
<code>T2
</code> must be integer types, or integer vectors with
4093 the same number of elements.
<code>T2
</code> must be wider than
<code>T1
</code>.
</p>
4094 <p>The instruction fills the high order bits of the value with zero bits until it
4095 reaches the size of the destination type. When zero extending from i1, the
4096 result will always be either
0 or
1.
</p>
4097 <p><strong>Constraints
</strong>:
</p>
4098 <pre class=
"prettyprint">
4099 AA == AbbrevIndex(A)
&
4100 TypeOf(V) == T1
&
4101 VV == RelativeIndex(V)
&
4102 %tTT2 == TypeID(T2)
&
4103 BitSizeOf(UnderlyingType(T1))
< BitSizeOf(UnderlyingType(T2))
&
4104 UnderlyingCount(T1) == UnderlyingCount(T2)
&
4105 IsInteger(UnderlyingType(T1))
&
4106 IsInteger(UnderlyingType(T2))
&
4109 <p><strong>Updates
</strong>:
</p>
4110 <pre class=
"prettyprint">
4114 <p><strong>Examples
</strong>:
</p>
4115 <pre class=
"prettyprint">
4116 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4117 48:
0|
3:
<1,
5> | count
5;
4118 50:
4|
3:
<7,
64> |
@t0 = i64;
4119 53:
6|
3:
<7,
32> |
@t1 = i32;
4120 57:
0|
3:
<21,
0,
0> |
@t2 = i64 ();
4121 60:
2|
3:
<7,
8> |
@t3 = i8;
4122 62:
6|
3:
<2> |
@t4 = void;
4123 64:
4|
0:
<65534> | }
4125 100:
0|
1:
<65535,
12,
2> | function i64
@f0() { // BlockID =
12
4126 108:
0|
3:
<1,
1> | blocks
1;
4127 110:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
4128 120:
0|
3:
<1,
3> | i8:
4129 122:
4|
3:
<4,
2> | %c0 = i8
1;
4130 125:
0|
0:
<65534> | }
4132 128:
0|
3:
<3,
1,
1,
1> | %v0 = zext i8 %c0 to i32;
4133 132:
0|
3:
<3,
1,
0,
1> | %v1 = zext i32 %v0 to i64;
4134 136:
0|
3:
<10,
1> | ret i64 %v1;
4135 138:
4|
0:
<65534> | }
4137 <h3 id=
"sign-extending-instruction">Sign Extending Instruction
</h3>
4138 <p>The sign extending instruction takes a value to cast, and a type to extend it
4139 to. Both types must be integer types, or integral vectors with the same number
4140 of elements. The bit size of the source type must be smaller than the bit size
4141 of the destination type. Equal sized types are not allowed.
</p>
4142 <p><strong>Syntax
</strong>:
</p>
4143 <pre class=
"prettyprint">
4144 %vN = sext T1 V to T2;
<A
>
4146 <p><strong>Record
</strong>:
</p>
4147 <pre class=
"prettyprint">
4148 AA:
<3, VV, TT2,
2>
4150 <p><strong>Semantics
</strong>:
</p>
4151 <p>The sign extending instruction takes a value
<code>V
</code>, and expands it to type
4152 <code>T2
</code>. Both
<code>T1
</code> and
<code>T2
</code> must be integer types, or integer vectors with
4153 the same number of integers.
<code>T2
</code> has to be wider than
<code>T1
</code>.
</p>
4154 <p>When sign extending, the instruction fills the high order bits of the value with
4155 the (current) high order bit of the value. When sign extending from i1, the
4156 extension always results in -
1 or
0.
</p>
4157 <p><strong>Constraints
</strong>:
</p>
4158 <pre class=
"prettyprint">
4159 AA == AbbrevIndex(A)
&
4160 TypeOf(V) == T1
&
4161 VV == RelativeIndex(V)
&
4162 %tTT2 == TypeID(T2)
&
4163 BitSizeOf(UnderlyingType(T1))
< BitSizeOf(UnderlyingType(T2))
&
4164 UnderlyingCount(T1) == UnderlyingCount(T2)
&
4165 IsInteger(UnderlyingType(T1))
&
4166 IsInteger(UnderlyingType(T2))
&
4169 <p><strong>Updates
</strong>:
</p>
4170 <pre class=
"prettyprint">
4174 <p><strong>Examples
</strong>:
</p>
4175 <pre class=
"prettyprint">
4176 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4177 48:
0|
3:
<1,
5> | count
5;
4178 50:
4|
3:
<7,
64> |
@t0 = i64;
4179 53:
6|
3:
<7,
32> |
@t1 = i32;
4180 57:
0|
3:
<21,
0,
0> |
@t2 = i64 ();
4181 60:
2|
3:
<7,
8> |
@t3 = i8;
4182 62:
6|
3:
<2> |
@t4 = void;
4183 64:
4|
0:
<65534> | }
4185 100:
0|
1:
<65535,
12,
2> | function i64
@f0() { // BlockID =
12
4186 108:
0|
3:
<1,
1> | blocks
1;
4187 110:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
4188 120:
0|
3:
<1,
3> | i8:
4189 122:
4|
3:
<4,
3> | %c0 = i8 -
1;
4190 125:
0|
0:
<65534> | }
4192 128:
0|
3:
<3,
1,
1,
2> | %v0 = sext i8 %c0 to i32;
4193 132:
0|
3:
<3,
1,
0,
2> | %v1 = sext i32 %v0 to i64;
4194 136:
0|
3:
<10,
1> | ret i64 %v1;
4195 138:
4|
0:
<65534> | }
4197 <h3 id=
"floating-point-extending-instruction">Floating Point Extending Instruction
</h3>
4198 <p>The floating point extending instruction takes a value to extend, and a type to
4199 extend it to. Both types must either be floating point types, or vectors of
4200 floating point types with the same number of elements. The source value must be
4201 <code>float
</code> while the destination is
<code>double
</code>. If the source is a vector, the
4202 destination must also be vector with the same size as the source.
</p>
4203 <p><strong>Syntax
</strong>:
</p>
4204 <pre class=
"prettyprint">
4205 %vN = fpext T1 V to T2;
<A
>
4207 <p><strong>Record
</strong>:
</p>
4208 <pre class=
"prettyprint">
4209 AA:
<3, VV, TT2,
8>
4211 <p><strong>Semantics
</strong>:
</p>
4212 <p>The floating point extending instruction converts floating point values.
4213 <code>V
</code> is the value to extend, and
<code>T2
</code> is the type to extend it
4214 to. Both
<code>T1
</code> and
<code>T2
</code> must be floating point types, or floating point
4215 vector types with the same number of floating point values.
<code>T1
</code> contains
4216 <code>float
</code> while
<code>T2
</code> contains
<code>double
</code>.
</p>
4217 <p><strong>Constraints
</strong>:
</p>
4218 <pre class=
"prettyprint">
4219 AA == AbbrevIndex(A)
&
4220 TypeOf(V) == T1
&
4221 VV == RelativeIndex(V)
&
4222 %tTT2 == TypeID(T2)
&
4223 BitSizeOf(UnderlyingType(T1))
< BitSizeOf(UnderlyingType(T2))
&
4224 UnderlyingCount(T1) == UnderlyingCount(T2)
&
4225 IsFloat(UnderlyingType(T1))
&
4226 IsFloat(UnderlyingType(T2))
&
4229 <p><strong>Updates
</strong>:
</p>
4230 <pre class=
"prettyprint">
4234 <p><strong>Examples
</strong>:
</p>
4235 <pre class=
"prettyprint">
4236 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4237 48:
0|
3:
<1,
4> | count
4;
4238 50:
4|
3:
<4> |
@t0 = double;
4239 52:
2|
3:
<3> |
@t1 = float;
4240 54:
0|
3:
<21,
0,
0,
1> |
@t2 = double (float);
4241 58:
0|
3:
<2> |
@t3 = void;
4242 59:
6|
0:
<65534> | }
4244 92:
0|
1:
<65535,
12,
2> | function double
@f0(float %p0) {
4246 100:
0|
3:
<1,
1> | blocks
1;
4248 102:
4|
3:
<3,
1,
0,
8> | %v0 = fpext float %p0 to double;
4249 106:
4|
3:
<10,
1> | ret double %v0;
4250 109:
0|
0:
<65534> | }
4252 <h3 id=
"floating-point-to-unsigned-integer-instruction">Floating Point to Unsigned Integer Instruction
</h3>
4253 <p>The floating point to unsigned integer instruction converts floating point
4254 values to unsigned integers.
</p>
4255 <p><strong>Syntax
</strong>:
</p>
4256 <pre class=
"prettyprint">
4257 %vN = fptoui T1 V to T2;
<A
>
4259 <p><strong>Record
</strong>:
</p>
4260 <pre class=
"prettyprint">
4261 AA:
<3, VV, TT2,
3>
4263 <p><strong>Semantics
</strong>:
</p>
4264 <p>The floating point to unsigned integer instruction converts floating point
4265 value(s) in
<code>V
</code> to its unsigned integer equivalent of type
<code>T2
</code>.
<code>T1
</code> must
4266 be a floating point type, or a floating point vector type.
<code>T2
</code> must be an
4267 integer type, or an integer vector type. If either type is a vector type, they
4268 both must have the same number of elements.
</p>
4269 <p><strong>Constraints
</strong>:
</p>
4270 <pre class=
"prettyprint">
4271 AA == AbbrevIndex(A)
&
4272 TypeOf(V) == T1
&
4273 VV == RelativeIndex(V)
&
4274 %tTT2 == TypeID(T2)
&
4275 UnderlyingCount(T1) == UnderlyingCount(T2)
&
4276 IsFloat(UnderlyingType(T1))
&
4277 IsInteger(UnderlyingType(T2))
&
4280 <p><strong>Updates
</strong>:
</p>
4281 <pre class=
"prettyprint">
4285 <p><strong>Examples
</strong>:
</p>
4286 <pre class=
"prettyprint">
4287 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4288 48:
0|
3:
<1,
6> | count
6;
4289 50:
4|
3:
<3> |
@t0 = float;
4290 52:
2|
3:
<4> |
@t1 = double;
4291 54:
0|
3:
<2> |
@t2 = void;
4292 55:
6|
3:
<21,
0,
2,
0,
1> |
@t3 = void (float, double);
4293 60:
4|
3:
<7,
32> |
@t4 = i32;
4294 63:
6|
3:
<7,
16> |
@t5 = i16;
4295 66:
2|
0:
<65534> | }
4297 100:
0|
1:
<65535,
12,
2> | function
4298 | | void
@f0(float %p0, double %p1) {
4300 108:
0|
3:
<1,
1> | blocks
1;
4302 110:
4|
3:
<3,
2,
4,
3> | %v0 = fptoui float %p0 to i32;
4303 114:
4|
3:
<3,
2,
5,
3> | %v1 = fptoui double %p1 to i16;
4304 118:
4|
3:
<10> | ret void;
4305 120:
2|
0:
<65534> | }
4307 <h3 id=
"floating-point-to-signed-integer-instruction">Floating Point to Signed Integer Instruction
</h3>
4308 <p>The floating point to signed integer instruction converts floating point
4309 values to signed integers.
</p>
4310 <p><strong>Syntax
</strong>:
</p>
4311 <pre class=
"prettyprint">
4312 %vN = fptosi T1 V to T2;
<A
>
4314 <p><strong>Record
</strong>:
</p>
4315 <pre class=
"prettyprint">
4316 AA:
<3, VV, TT2,
4>
4318 <p><strong>Semantics
</strong>:
</p>
4319 <p>The floating point to signed integer instruction converts floating point
4320 value(s) in
<code>V
</code> to its signed integer equivalent of type
<code>T2
</code>.
<code>T1
</code> must
4321 be a floating point type, or a floating point vector type.
<code>T2
</code> must be an
4322 integer type, or an integer vector type. If either type is a vector type, they
4323 both must have the same number of elements.
</p>
4324 <p><strong>Constraints
</strong>:
</p>
4325 <pre class=
"prettyprint">
4326 AA == AbbrevIndex(A)
&
4327 TypeOf(V) == T1
&
4328 VV == RelativeIndex(V)
&
4329 %tTT2 = TypeID(T2)
&
4330 UnderlyingCount(T1) = UnderlyingCount(T2)
&
4331 IsFloat(UnderlyingType(T1))
&
4332 IsInteger(UnderlyingType(T2))
&
4335 <p><strong>Updates
</strong>:
</p>
4336 <pre class=
"prettyprint">
4340 <p><strong>Examples
</strong>:
</p>
4341 <pre class=
"prettyprint">
4342 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4343 48:
0|
3:
<1,
6> | count
6;
4344 50:
4|
3:
<3> |
@t0 = float;
4345 52:
2|
3:
<4> |
@t1 = double;
4346 54:
0|
3:
<2> |
@t2 = void;
4347 55:
6|
3:
<21,
0,
2,
0,
1> |
@t3 = void (float, double);
4348 60:
4|
3:
<7,
8> |
@t4 = i8;
4349 63:
0|
3:
<7,
16> |
@t5 = i16;
4350 65:
4|
0:
<65534> | }
4352 100:
0|
1:
<65535,
12,
2> | function
4353 | | void
@f0(float %p0, double %p1) {
4355 108:
0|
3:
<1,
1> | blocks
1;
4357 110:
4|
3:
<3,
2,
4,
4> | %v0 = fptosi float %p0 to i8;
4358 114:
4|
3:
<3,
2,
5,
4> | %v1 = fptosi double %p1 to i16;
4359 118:
4|
3:
<10> | ret void;
4360 120:
2|
0:
<65534> | }
4362 <h3 id=
"unsigned-integer-to-floating-point-instruction">Unsigned Integer to Floating Point Instruction
</h3>
4363 <p>The unsigned integer to floating point instruction converts unsigned integers to
4364 floating point values.
</p>
4365 <p><strong>Syntax
</strong>:
</p>
4366 <pre class=
"prettyprint">
4367 %vN = uitofp T1 V to T2;
<A
>
4369 <p><strong>Record
</strong>:
</p>
4370 <pre class=
"prettyprint">
4371 AA:
<3, VV, TT2,
5>
4373 <p><strong>Semantics
</strong>:
</p>
4374 <p>The unsigned integer to floating point instruction converts unsigned integer(s)
4375 to its floating point equivalent of type
<code>T2
</code>.
<code>T1
</code> must be an integer type,
4376 or a integer vector type.
<code>T2
</code> must be a floating point type, or a floating
4377 point vector type. If either type is a vector type, they both must have the same
4378 number of elements.
</p>
4379 <p><strong>Constraints
</strong>:
</p>
4380 <pre class=
"prettyprint">
4381 AA == AbbrevIndex(A)
&
4382 TypeOf(V) == T1
&
4383 VV == RelativeIndex(V)
&
4384 %tTT2 = TypeID(T2)
&
4385 UnderlyingCount(T1) == UnderlyingCount(T2)
&
4386 IsInteger(UnderlyingType(T1))
&
4387 IsFloat(UnderlyingType(T2))
&
4390 <p><strong>Updates
</strong>:
</p>
4391 <pre class=
"prettyprint">
4395 <p><strong>Examples
</strong>:
</p>
4396 <pre class=
"prettyprint">
4397 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4398 48:
0|
3:
<1,
7> | count
7;
4399 50:
4|
3:
<7,
32> |
@t0 = i32;
4400 53:
6|
3:
<7,
64> |
@t1 = i64;
4401 57:
0|
3:
<2> |
@t2 = void;
4402 58:
6|
3:
<3> |
@t3 = float;
4403 60:
4|
3:
<21,
0,
2,
0,
1> |
@t4 = void (i32, i64);
4404 65:
2|
3:
<7,
1> |
@t5 = i1;
4405 67:
6|
3:
<4> |
@t6 = double;
4406 69:
4|
0:
<65534> | }
4408 104:
0|
1:
<65535,
12,
2> | function void
@f0(i32 %p0, i64 %p1) {
4410 112:
0|
3:
<1,
1> | blocks
1;
4411 114:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
4412 124:
0|
3:
<1,
5> | i1:
4413 126:
4|
3:
<4,
3> | %c0 = i1
1;
4414 129:
0|
0:
<65534> | }
4416 132:
0|
3:
<3,
1,
6,
5> | %v0 = uitofp i1 %c0 to double;
4417 136:
0|
3:
<3,
4,
3,
5> | %v1 = uitofp i32 %p0 to float;
4418 140:
0|
3:
<3,
4,
3,
5> | %v2 = uitofp i64 %p1 to float;
4419 144:
0|
3:
<10> | ret void;
4420 145:
6|
0:
<65534> | }
4422 <h3 id=
"signed-integer-to-floating-point-instruction">Signed Integer to Floating Point Instruction
</h3>
4423 <p>The signed integer to floating point instruction converts signed integers to
4424 floating point values.
</p>
4425 <p><strong>Syntax
</strong>:
</p>
4426 <pre class=
"prettyprint">
4427 %vN = sitofp T1 V to T2;
<A
>
4429 <p><strong>Record
</strong>:
</p>
4430 <pre class=
"prettyprint">
4431 AA:
<3, VV, TT2,
6>
4433 <p><strong>Semantics
</strong>:
</p>
4434 <p>The signed integer to floating point instruction converts signed integer(s) to
4435 its floating point equivalent of type
<code>T2
</code>.
<code>T1
</code> must be an integer type, or
4436 a integer vector type.
<code>T2
</code> must be a floating point type, or a floating point
4437 vector type. If either type is a vector type, they both must have the same
4438 number of elements.
</p>
4439 <p><strong>Constraints
</strong>:
</p>
4440 <pre class=
"prettyprint">
4441 AA == AbbrevIndex(A)
&
4442 TypeOf(V) == T1
&
4443 VV == RelativeIndex(V)
&
4444 %tTT2 = TypeID(T2)
&
4445 UnderlyingCount(T1) == UnderlyingCount(T2)
&
4446 IsInteger(UnderlyingType(T1))
&
4447 IsFloat(UnderlyingType(T2))
&
4450 <p><strong>Updates
</strong>:
</p>
4451 <pre class=
"prettyprint">
4455 <p><strong>Examples
</strong>:
</p>
4456 <pre class=
"prettyprint">
4457 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4458 48:
0|
3:
<1,
7> | count
7;
4459 50:
4|
3:
<7,
32> |
@t0 = i32;
4460 53:
6|
3:
<7,
64> |
@t1 = i64;
4461 57:
0|
3:
<2> |
@t2 = void;
4462 58:
6|
3:
<3> |
@t3 = float;
4463 60:
4|
3:
<21,
0,
2,
0,
1> |
@t4 = void (i32, i64);
4464 65:
2|
3:
<7,
8> |
@t5 = i8;
4465 67:
6|
3:
<4> |
@t6 = double;
4466 69:
4|
0:
<65534> | }
4468 104:
0|
1:
<65535,
12,
2> | function void
@f0(i32 %p0, i64 %p1) {
4470 112:
0|
3:
<1,
1> | blocks
1;
4471 114:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
4472 124:
0|
3:
<1,
5> | i8:
4473 126:
4|
3:
<4,
3> | %c0 = i8 -
1;
4474 129:
0|
0:
<65534> | }
4476 132:
0|
3:
<3,
1,
6,
6> | %v0 = sitofp i8 %c0 to double;
4477 136:
0|
3:
<3,
4,
3,
6> | %v1 = sitofp i32 %p0 to float;
4478 140:
0|
3:
<3,
4,
3,
6> | %v2 = sitofp i64 %p1 to float;
4479 144:
0|
3:
<10> | ret void;
4480 145:
6|
0:
<65534> | }
4482 <h3 id=
"bitcast-instruction">Bitcast Instruction
</h3>
4483 <p>The bitcast instruction converts the type of the value without changing the bit
4484 contents of the value. The bit size of the type of the value must be the same as
4485 the bit size of the cast type.
</p>
4486 <p><strong>Syntax
</strong>:
</p>
4487 <pre class=
"prettyprint">
4488 %vN = bitcast T1 V to T2;
<A
>
4490 <p><strong>Record
</strong>:
</p>
4491 <pre class=
"prettyprint">
4492 AA:
<3, VV, TT2,
11>
4494 <p><strong>Semantics
</strong>:
</p>
4495 <p>The bitcast instruction converts the type of value
<code>V
</code> to type
<code>T2
</code>.
<code>T1
</code>
4496 and
<code>T2
</code> must be primitive types or vectors, and define the same number of
4498 <p><strong>Constraints
</strong>:
</p>
4499 <pre class=
"prettyprint">
4500 AA == AbbrevIndex(A)
&
4501 TypeOf(V) == T1
&
4502 VV = RelativeIndex(V)
&
4503 %tTT2 = TypeID(T2)
&
4504 BitSizeOf(T1) == BitSizeOf(T2)
&
4507 <p><strong>Updates
</strong>:
</p>
4508 <pre class=
"prettyprint">
4512 <p><strong>Examples
</strong>:
</p>
4513 <pre class=
"prettyprint">
4514 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4515 48:
0|
3:
<1,
6> | count
6;
4516 50:
4|
3:
<3> |
@t0 = float;
4517 52:
2|
3:
<7,
64> |
@t1 = i64;
4518 55:
4|
3:
<2> |
@t2 = void;
4519 57:
2|
3:
<21,
0,
2,
0,
1> |
@t3 = void (float, i64);
4520 62:
0|
3:
<7,
32> |
@t4 = i32;
4521 65:
2|
3:
<4> |
@t5 = double;
4522 67:
0|
0:
<65534> | }
4524 100:
0|
1:
<65535,
12,
2> | function void
@f0(float %p0, i64 %p1)
4525 | | { // BlockID =
12
4526 108:
0|
3:
<1,
1> | blocks
1;
4528 110:
4|
3:
<3,
2,
4,
11> | %v0 = bitcast float %p0 to i32;
4529 114:
4|
3:
<3,
2,
5,
11> | %v1 = bitcast i64 %p1 to double;
4530 118:
4|
3:
<10> | ret void;
4531 120:
2|
0:
<65534> | }
4533 <h2 id=
"comparison-instructions"><span id=
"link-for-compare-instructions"></span>Comparison Instructions
</h2>
4534 <p>The comparison instructions compare values and generates a boolean (i1) result
4535 for each pair of compared values. There are different comparison operations for
4536 integer and floating point values.
</p>
4537 <h3 id=
"integer-comparison-instructions">Integer Comparison Instructions
</h3>
4538 <p>The integer comparison instruction compares integer values and returns a
4539 boolean (i1) result for each pair of compared values.
</p>
4540 <p><strong>Syntax
</strong>:
</p>
4541 <pre class=
"prettyprint">
4542 %vN = icmp C T V1, V2;
<A
>
4544 <p><strong>Record
</strong>:
</p>
4545 <pre class=
"prettyprint">
4546 AA:
<9, VV1, VV2, CC
>
4548 <p><strong>Semantics
</strong>:
</p>
4549 <p>The integer comparison instruction compares integer values and returns a boolean
4550 (i1) result for each pair of compared values in
<code>V1
</code> and
<code>V2
</code>.
<code>V1
</code> and
4551 <code>V2
</code> must be of type
<code>T
</code>.
<code>T
</code> must be an integer type, or an integer
4552 vector type. Condition code
<code>C
</code> is the condition applied to all elements in
4553 <code>V1
</code> and
<code>V2
</code>. Each comparison always yields an i1. If
<code>T
</code> is a primitive
4554 type, the resulting type is i1. If
<code>T
</code> is a vector, then the resulting type is
4555 a vector of i1 with the same size as
<code>T
</code>.
</p>
4556 <p>Legal test conditions are:
</p>
4557 <table border=
"1" class=
"docutils">
4560 <thead valign=
"bottom">
4561 <tr class=
"row-odd"><th class=
"head">C
</th>
4562 <th class=
"head">CC
</th>
4563 <th class=
"head">Operator
</th>
4566 <tbody valign=
"top">
4567 <tr class=
"row-even"><td>eq
</td>
4571 <tr class=
"row-odd"><td>ne
</td>
4575 <tr class=
"row-even"><td>ugt
</td>
4577 <td>unsigned greater than
</td>
4579 <tr class=
"row-odd"><td>uge
</td>
4581 <td>unsigned greater than or equal
</td>
4583 <tr class=
"row-even"><td>ult
</td>
4585 <td>unsigned less than
</td>
4587 <tr class=
"row-odd"><td>ule
</td>
4589 <td>unsigned less than or equal
</td>
4591 <tr class=
"row-even"><td>sgt
</td>
4593 <td>signed greater than
</td>
4595 <tr class=
"row-odd"><td>sge
</td>
4597 <td>signed greater than or equal
</td>
4599 <tr class=
"row-even"><td>slt
</td>
4601 <td>signed less than
</td>
4603 <tr class=
"row-odd"><td>sle
</td>
4605 <td>signed less than or equal
</td>
4609 <p><strong>Constraints
</strong>:
</p>
4610 <pre class=
"prettyprint">
4611 AA == AbbrevIndex(A)
&
4612 IsInteger(UnderlyingType(T)
&
4613 T == TypeOf(V1) == TypeOf(V2)
&
4616 <p><strong>Updates
</strong>:
</p>
4617 <pre class=
"prettyprint">
4620 TypeOf(%vN) =
<UnderlyingCount(T), i1
>
4625 <p><strong>Examples
</strong>:
</p>
4626 <pre class=
"prettyprint">
4627 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4628 48:
0|
3:
<1,
4> | count
4;
4629 50:
4|
3:
<7,
32> |
@t0 = i32;
4630 53:
6|
3:
<7,
1> |
@t1 = i1;
4631 56:
2|
3:
<2> |
@t2 = void;
4632 58:
0|
3:
<21,
0,
2> |
@t3 = void ();
4633 61:
2|
0:
<65534> | }
4635 108:
0|
1:
<65535,
12,
2> | function void
@f0() {
4637 116:
0|
3:
<1,
1> | blocks
1;
4638 118:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
4639 128:
0|
3:
<1,
0> | i32:
4640 130:
4|
3:
<4,
0> | %c0 = i32
0;
4641 133:
0|
3:
<4,
2> | %c1 = i32
1;
4642 135:
4|
0:
<65534> | }
4644 136:
0|
3:
<28,
2,
1,
32> | %v0 = icmp eq i32 %c0, %c1;
4645 140:
6|
3:
<28,
3,
2,
33> | %v1 = icmp ne i32 %c0, %c1;
4646 145:
4|
3:
<28,
4,
3,
34> | %v2 = icmp ugt i32 %c0, %c1;
4647 150:
2|
3:
<28,
5,
4,
36> | %v3 = icmp ult i32 %c0, %c1;
4648 155:
0|
3:
<28,
6,
5,
37> | %v4 = icmp ule i32 %c0, %c1;
4649 159:
6|
3:
<28,
7,
6,
38> | %v5 = icmp sgt i32 %c0, %c1;
4650 164:
4|
3:
<28,
8,
7,
38> | %v6 = icmp sgt i32 %c0, %c1;
4651 169:
2|
3:
<28,
9,
8,
39> | %v7 = icmp sge i32 %c0, %c1;
4652 174:
0|
3:
<28,
10,
9,
40> | %v8 = icmp slt i32 %c0, %c1;
4653 178:
6|
3:
<28,
11,
10,
41> | %v9 = icmp sle i32 %c0, %c1;
4654 183:
4|
3:
<10> | ret void;
4655 185:
2|
0:
<65534> | }
4657 <h3 id=
"floating-point-comparison-instructions">Floating Point Comparison Instructions
</h3>
4658 <p>The floating point comparison instruction compares floating point values and
4659 returns a boolean (i1) result for each pair of compared values.
</p>
4660 <p><strong>Syntax
</strong>:
</p>
4661 <pre class=
"prettyprint">
4662 %vN = fcmp C T V1, V2;
<A
>
4664 <p><strong>Record
</strong>:
</p>
4665 <pre class=
"prettyprint">
4666 AA:
<9, VV1, VV2, CC
>
4668 <p><strong>Semantics
</strong>:
</p>
4669 <p>The floating point comparison instruction compares floating point values and
4670 returns a boolean (i1) result for each pair of compared values in
<code>V1
</code> and
4671 <code>V2
</code>.
<code>V1
</code> and
<code>V2
</code> must be of type
<code>T
</code>.
<code>T
</code> must be a floating point
4672 type, or a floating point vector type. Condition code
<code>C
</code> is the condition
4673 applied to all elements in
<code>V1
</code> and
<code>V2
</code>. Each comparison always yields an
4674 i1. If
<code>T
</code> is a primitive type, the resulting type is i1. If
<code>T
</code> is a
4675 vector, then the resulting type is a vector of i1 with the same size as
<code>T
</code>.
</p>
4676 <p>Legal test conditions are:
</p>
4677 <table border=
"1" class=
"docutils">
4680 <thead valign=
"bottom">
4681 <tr class=
"row-odd"><th class=
"head">C
</th>
4682 <th class=
"head">CC
</th>
4683 <th class=
"head">Operator
</th>
4686 <tbody valign=
"top">
4687 <tr class=
"row-even"><td>false
</td>
4689 <td>Always false
</td>
4691 <tr class=
"row-odd"><td>oeq
</td>
4693 <td>Ordered and equal
</td>
4695 <tr class=
"row-even"><td>ogt
</td>
4697 <td>Ordered and greater than
</td>
4699 <tr class=
"row-odd"><td>oge
</td>
4701 <td>Ordered and greater than or equal
</td>
4703 <tr class=
"row-even"><td>olt
</td>
4705 <td>Ordered and less than
</td>
4707 <tr class=
"row-odd"><td>ole
</td>
4709 <td>Ordered and less than or equal
</td>
4711 <tr class=
"row-even"><td>one
</td>
4713 <td>Ordered and not equal
</td>
4715 <tr class=
"row-odd"><td>ord
</td>
4717 <td>Ordered (no NaNs)
</td>
4719 <tr class=
"row-even"><td>uno
</td>
4721 <td>Unordered (either NaNs)
</td>
4723 <tr class=
"row-odd"><td>ueq
</td>
4725 <td>Unordered or equal
</td>
4727 <tr class=
"row-even"><td>ugt
</td>
4729 <td>Unordered or greater than
</td>
4731 <tr class=
"row-odd"><td>uge
</td>
4733 <td>Unordered or greater than or equal
</td>
4735 <tr class=
"row-even"><td>ult
</td>
4737 <td>Unordered or less than
</td>
4739 <tr class=
"row-odd"><td>ule
</td>
4741 <td>Unordered or less than or equal
</td>
4743 <tr class=
"row-even"><td>une
</td>
4745 <td>Unordered or not equal
</td>
4747 <tr class=
"row-odd"><td>true
</td>
4749 <td>Always true
</td>
4753 <p><strong>Constraints
</strong>:
</p>
4754 <pre class=
"prettyprint">
4755 AA == AbbrevIndex(A)
&
4756 IsFloat(UnderlyingType(T)
&
4757 T == TypeOf(V1) == TypeOf(V2)
&
4760 <p><strong>Updates
</strong>:
</p>
4761 <pre class=
"prettyprint">
4764 TypeOf(%vN) =
<UnderlyingCount(T), i1
>
4769 <p><strong>Examples
</strong>:
</p>
4770 <pre class=
"prettyprint">
4771 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4772 48:
0|
3:
<1,
4> | count
4;
4773 50:
4|
3:
<3> |
@t0 = float;
4774 52:
2|
3:
<7,
1> |
@t1 = i1;
4775 54:
6|
3:
<2> |
@t2 = void;
4776 56:
4|
3:
<21,
0,
2> |
@t3 = void ();
4777 59:
6|
0:
<65534> | }
4779 108:
0|
1:
<65535,
12,
2> | function void
@f0() {
4781 116:
0|
3:
<1,
1> | blocks
1;
4782 118:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
4783 128:
0|
3:
<1,
0> | float:
4784 130:
4|
3:
<6,
0> | %c0 = float
0;
4785 133:
0|
3:
<6,
1065353216> | %c1 = float
1;
4786 139:
2|
0:
<65534> | }
4788 140:
0|
3:
<28,
2,
1,
0> | %v0 = fcmp false float %c0, %c1;
4789 144:
0|
3:
<28,
3,
2,
1> | %v1 = fcmp oeq float %c0, %c1;
4790 148:
0|
3:
<28,
4,
3,
2> | %v2 = fcmp ogt float %c0, %c1;
4791 152:
0|
3:
<28,
5,
4,
3> | %v3 = fcmp oge float %c0, %c1;
4792 156:
0|
3:
<28,
6,
5,
4> | %v4 = fcmp olt float %c0, %c1;
4793 160:
0|
3:
<28,
7,
6,
5> | %v5 = fcmp ole float %c0, %c1;
4794 164:
0|
3:
<28,
8,
7,
6> | %v6 = fcmp one float %c0, %c1;
4795 168:
0|
3:
<28,
9,
8,
7> | %v7 = fcmp ord float %c0, %c1;
4796 172:
0|
3:
<28,
10,
9,
9> | %v8 = fcmp ueq float %c0, %c1;
4797 176:
0|
3:
<28,
11,
10,
10> | %v9 = fcmp ugt float %c0, %c1;
4798 180:
0|
3:
<28,
12,
11,
11> | %v10 = fcmp uge float %c0, %c1;
4799 184:
0|
3:
<28,
13,
12,
12> | %v11 = fcmp ult float %c0, %c1;
4800 188:
0|
3:
<28,
14,
13,
13> | %v12 = fcmp ule float %c0, %c1;
4801 192:
0|
3:
<28,
15,
14,
14> | %v13 = fcmp une float %c0, %c1;
4802 196:
0|
3:
<28,
16,
15,
8> | %v14 = fcmp uno float %c0, %c1;
4803 200:
0|
3:
<28,
17,
16,
15> | %v15 = fcmp true float %c0, %c1;
4804 204:
0|
3:
<10> | ret void;
4805 205:
6|
0:
<65534> | }
4806 208:
0|
0:
<65534> |}
4808 <h2 id=
"vector-instructions"><span id=
"link-for-vector-instructions"></span>Vector Instructions
</h2>
4809 <p>PNaClAsm supports several instructions that process vectors. This includes the
4810 <a class=
"reference internal" href=
"#link-for-integer-binary-instructions"><em>integer
</em></a> and
<a class=
"reference internal" href=
"#link-for-floating-point-binary-instructions"><em>floating
4811 point
</em></a> binary instructions as well
4812 as
<a class=
"reference internal" href=
"#link-for-compare-instructions"><em>compare
</em></a> instructions. These
4813 instructions work with vectors and generate resulting (new) vectors. This
4814 section introduces the instructions to construct vectors and extract results.
</p>
4815 <h3 id=
"insert-element-instruction"><span id=
"link-for-insert-element-instruction-section"></span>Insert Element Instruction
</h3>
4816 <p>The
<em>insert element
</em> instruction inserts a scalar value into a vector at a
4817 specified index. The
<em>insert element
</em> instruction takes an existing vector and
4818 puts a scalar value in one of the elements of the vector.
</p>
4819 <p>The
<em>insert element
</em> instruction can be used to construct a vector, one element
4820 at a time. At first glance, it may appear that one can
’t construct a vector,
4821 since the
<em>insert element
</em> instruction needs a vector to insert elements into.
</p>
4822 <p>The key to understanding vector construction is understand that one can create
4823 an
<a class=
"reference internal" href=
"#link-for-undefined-literal"><em>undefined
</em></a> vector literal. Using that
4824 constant as a starting point, one can built up the wanted vector by a sequence
4825 of
<em>insert element
</em> instructions.
</p>
4826 <p><strong>Syntax
</strong>:
</p>
4827 <pre class=
"prettyprint">
4828 %vN = insertelement TV V, TE E, i32 I;
<A
>
4830 <p><strong>Record
</strong>:
</p>
4831 <pre class=
"prettyprint">
4832 AA:
<7, VV, EE, II
>
4834 <p><strong>Semantics
</strong>:
</p>
4835 <p>The
<em>insert element
</em> instruction inserts scalar value
<code>E
</code> into index
<code>I
</code> of
4836 vector
<code>V
</code>.
<code>%vN
</code> holds the updated vector. Type
<code>TV
</code> is the type of
4837 vector. It is also the type of updated vector
<code>%vN
</code>. Type
<code>TE
</code> is the type
4838 of scalar value
<code>E
</code> and must be the element type of vector
<code>V
</code>.
<code>I
</code> must
4839 be an
<a class=
"reference internal" href=
"#link-for-integer-literal"><em>i32 literal
</em></a>.
</p>
4840 <p>If
<code>I
</code> exceeds the length of
<code>V
</code>, the result is undefined.
</p>
4841 <p><strong>Constraints
</strong>:
</p>
4842 <pre class=
"prettyprint">
4843 AA == AbbrevIndex(A)
&
4845 TypeOf(V) == TV
&
4846 UnderlyingType(TV) == TE
&
4847 TypeOf(I) == i32
&
4850 <p><strong>Updates
</strong>:
</p>
4851 <pre class=
"prettyprint">
4855 <p><strong>Examples
</strong>:
</p>
4856 <pre class=
"prettyprint">
4857 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4858 48:
0|
3:
<1,
5> | count
5;
4859 50:
4|
3:
<7,
1> |
@t0 = i1;
4860 53:
0|
3:
<12,
4,
0> |
@t1 =
<4 x i1
>;
4861 56:
2|
3:
<7,
32> |
@t2 = i32;
4862 59:
4|
3:
<2> |
@t3 = void;
4863 61:
2|
3:
<21,
0,
3> |
@t4 = void ();
4864 64:
4|
0:
<65534> | }
4866 116:
0|
1:
<65535,
12,
2> | function void
@f0() {
4868 124:
0|
3:
<1,
1> | blocks
1;
4869 126:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
4870 136:
0|
3:
<1,
0> | i1:
4871 138:
4|
3:
<4,
0> | %c0 = i1
0;
4872 141:
0|
3:
<4,
3> | %c1 = i1
1;
4873 143:
4|
3:
<1,
1> |
<4 x i1
>:
4874 146:
0|
3:
<3> | %c2 =
<4 x i1
> undef;
4875 147:
6|
3:
<1,
2> | i32:
4876 150:
2|
3:
<4,
0> | %c3 = i32
0;
4877 152:
6|
3:
<4,
2> | %c4 = i32
1;
4878 155:
2|
3:
<4,
4> | %c5 = i32
2;
4879 157:
6|
3:
<4,
6> | %c6 = i32
3;
4880 160:
2|
0:
<65534> | }
4882 164:
0|
3:
<7,
5,
7,
4> | %v0 = insertelement
<4 x i1
> %c2,
4883 | | i1 %c0, i32 %c3;
4884 168:
0|
3:
<7,
1,
7,
4> | %v1 = insertelement
<4 x i1
> %v0,
4885 | | i1 %c1, i32 %c4;
4886 172:
0|
3:
<7,
1,
9,
4> | %v2 = insertelement
<4 x i1
> %v1,
4887 | | i1 %c0, i32 %c5;
4888 176:
0|
3:
<7,
1,
9,
4> | %v3 = insertelement
<4 x i1
> %v2,
4889 | | i1 %c1, i32 %c6;
4890 180:
0|
3:
<10> | ret void;
4891 181:
6|
0:
<65534> | }
4893 <h3 id=
"extract-element-instruction">Extract Element Instruction
</h3>
4894 <p>The
<em>extract element
</em> instruction extracts a single scalar value from a vector
4895 at a specified index.
</p>
4896 <p><strong>Syntax
</strong>:
</p>
4897 <pre class=
"prettyprint">
4898 %vN = extractelement TV V, i32 I;
<A
>
4900 <p><strong>Record
</strong>:
</p>
4901 <pre class=
"prettyprint">
4902 AA:
<6, VV, II
>
4904 <p><strong>Semantics
</strong>:
</p>
4905 <p>The
<em>extract element
</em> instruction extracts the scalar value at index
<code>I
</code> from
4906 vector
<code>V
</code>. The extracted value is assigned to
<code>%vN
</code>. Type
<code>TV
</code> is the
4907 type of vector
<code>V
</code>.
<code>I
</code> must be an
<a class=
"reference internal" href=
"#link-for-integer-literal"><em>i32
4908 literal
</em></a>. The type of
<code>vN
</code> must be the element type
4909 of vector
<code>V
</code>.
</p>
4910 <p>If
<code>I
</code> exceeds the length of
<code>V
</code>, the result is undefined.
</p>
4911 <p><strong>Constraints
</strong>:
</p>
4912 <pre class=
"prettyprint">
4913 AA == AbbrevIndex(A)
&
4915 TypeOf(V) == TV
&
4916 TypeOf(I) == i32
&
4919 <p><strong>Updates
</strong>:
</p>
4920 <pre class=
"prettyprint">
4922 TypeOf(%vN) = UnderlyingType(TV);
4924 <p><strong>Examples
</strong>:
</p>
4925 <pre class=
"prettyprint">
4926 96:
0|
1:
<65535,
12,
2> | function void
@f0(
<4 x i32
> %p0) {
4928 104:
0|
3:
<1,
1> | blocks
1;
4929 106:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
4930 116:
0|
3:
<1,
0> | i32:
4931 118:
4|
3:
<4,
0> | %c0 = i32
0;
4932 121:
0|
0:
<65534> | }
4934 124:
0|
3:
<6,
2,
1> | %v0 =
4935 | | extractelement
<4 x i32
> %p0,
4937 127:
2|
3:
<10> | ret void;
4938 129:
0|
0:
<65534> | }
4940 <h2 id=
"other-instructions"><span id=
"link-for-other-pnaclasm-instructions"></span>Other Instructions
</h2>
4941 <p>This section defines miscellaneous instructions which defy better
4943 <h3 id=
"forward-type-declaration"><span id=
"link-for-forward-type-declaration-section"></span>Forward Type Declaration
</h3>
4944 <p>The forward type declaration exists to deal with the fact that all instruction
4945 values must have a type associated with them before they are used. For some
4946 simple functions one can easily topologically sort instructions so that
4947 instruction values are defined before they are used. However, if the
4948 implementation contains loops, the loop induced values can
’t be defined before
4950 <p>The solution is to forward declare the type of an instruction value. One could
4951 forward declare the types of all instructions at the beginning of the function
4952 block. However, this would make the corresponding file size considerably
4953 larger. Rather, one should only generate these forward type declarations
4954 sparingly and only when needed.
</p>
4955 <p><strong>Syntax
</strong>:
</p>
4956 <pre class=
"prettyprint">
4957 declare T %vN;
<A
>
4959 <p><strong>Record
</strong>:
</p>
4960 <pre class=
"prettyprint">
4961 AA:
<43, N, TT
>
4963 <p><strong>Semantics
</strong>:
</p>
4964 <p>The forward declare type declaration defines the type to be associated with a
4965 (not yet defined) instruction value
<code>%vN
</code>.
<code>T
</code> is the type of the value
4966 generated by the
<code>Nth
</code> value generating instruction in the function block.
</p>
4967 <p>Note: It is an error to define the type of
<code>%vN
</code> with a different type than
4968 will be generated by the
<code>Nth
</code> value generating instruction in the function
4970 <p>Also note that this construct is a declaration and not considered an
4971 instruction, even though it appears in the list of instruction records. Hence,
4972 they may appear before and between
<a class=
"reference internal" href=
"#link-for-phi-instruction-section"><em>phi
</em></a>
4973 instructions in a basic block.
</p>
4974 <p><strong>Constraints
</strong>:
</p>
4975 <pre class=
"prettyprint">
4976 AA = AbbrevIndex(A)
&
4979 <p><strong>Updates
</strong>:
</p>
4980 <pre class=
"prettyprint">
4983 <p><strong>Examples
</strong>:
</p>
4984 <pre class=
"prettyprint">
4985 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
4986 48:
0|
3:
<1,
4> | count
4;
4987 50:
4|
3:
<7,
32> |
@t0 = i32;
4988 53:
6|
3:
<2> |
@t1 = void;
4989 55:
4|
3:
<7,
1> |
@t2 = i1;
4990 58:
0|
3:
<21,
0,
1,
0> |
@t3 = void (i32);
4991 62:
0|
0:
<65534> | }
4993 108:
0|
1:
<65535,
12,
2> | function void
@f0(i32 %p0) {
4995 116:
0|
3:
<1,
7> | blocks
7;
4996 118:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
4997 128:
0|
3:
<1,
2> | i1:
4998 130:
4|
3:
<4,
3> | %c0 = i1
1;
4999 133:
0|
0:
<65534> | }
5001 136:
0|
3:
<11,
4> | br label %b4;
5003 138:
4|
3:
<43,
6,
0> | declare i32 %v3;
5004 142:
4|
3:
<2,
2,
4294967293,
0> | %v0 = add i32 %p0, %v3;
5005 151:
0|
3:
<11,
6> | br label %b6;
5007 153:
4|
3:
<43,
7,
0> | declare i32 %v4;
5008 157:
4|
3:
<2,
3,
4294967293,
0> | %v1 = add i32 %p0, %v4;
5009 166:
0|
3:
<11,
6> | br label %b6;
5011 168:
4|
3:
<2,
4,
4294967295,
0> | %v2 = add i32 %p0, %v3;
5012 177:
0|
3:
<11,
6> | br label %b6;
5014 179:
4|
3:
<2,
5,
5,
0> | %v3 = add i32 %p0, %p0;
5015 183:
4|
3:
<11,
1,
5,
5> | br i1 %c0, label %b1, label %b5;
5017 187:
4|
3:
<2,
1,
6,
0> | %v4 = add i32 %v3, %p0;
5018 191:
4|
3:
<11,
2,
3,
6> | br i1 %c0, label %b2, label %b3;
5020 195:
4|
3:
<10> | ret void;
5021 197:
2|
0:
<65534> | }
5023 <h3 id=
"phi-instruction"><span id=
"link-for-phi-instruction-section"></span>Phi Instruction
</h3>
5024 <p>The
<em>phi
</em> instruction is used to implement phi nodes in the SSA graph
5025 representing the function. Phi instructions can only appear at the beginning of
5026 a basic block. There must be no non-phi instructions (other than forward type
5027 declarations) between the start of the basic block and the
<em>phi
</em> instruction.
</p>
5028 <p>To clarify the origin of each incoming value, the incoming value is associated
5029 with the incoming edge from the corresponding predecessor block that the
5030 incoming value comes from.
</p>
5031 <p><strong>Syntax
</strong>:
</p>
5032 <pre class=
"prettyprint">
5033 %vN = phi T [V1, %bB1], ... , [VM, %bBM];
<A
>
5035 <p><strong>Record
</strong>:
</p>
5036 <pre class=
"prettyprint">
5037 AA:
<16, TT, VV1, B1, ..., VVM, BM
>
5039 <p><strong>Semantics
</strong>:
</p>
5040 <p>The phi instruction is used to implement phi nodes in the SSA graph representing
5041 the function.
<code>%vN
</code> is the resulting value of the corresponding phi
5042 node.
<code>T
</code> is the type of the phi node. Values
<code>V1
</code> through
<code>VM
</code> are the
5043 reaching definitions for the phi node while
<code>%bB1
</code> through
<code>%bBM
</code> are the
5044 corresponding predecessor blocks. Each
<code>VI
</code> reaches via the incoming
5045 predecessor edge from block
<code>%bBI
</code> (for
1 <= I
<= M). Type
<code>T
</code> must be the
5046 type associated with each
<code>VI
</code>.
</p>
5047 <p><strong>Constraints
</strong>:
</p>
5048 <pre class=
"prettyprint">
5049 AA == AbbrevIndex(A)
&
5051 TT == TypeID(T)
&
5052 T = TypeOf(VI) for all I,
1 <= I
<= M
&
5053 BI
< ExpectedBasicBlocks for all I,
1 <= I
<= M
&
5054 VVI = SignRotate(RelativeIndex(VI)) for all I,
1 <= I
<= M
&
5057 <p><strong>Updates
</strong>:
</p>
5058 <pre class=
"prettyprint">
5062 <p><strong>Examples
</strong>:
</p>
5063 <pre class=
"prettyprint">
5064 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
5065 48:
0|
3:
<1,
4> | count
4;
5066 50:
4|
3:
<7,
32> |
@t0 = i32;
5067 53:
6|
3:
<2> |
@t1 = void;
5068 55:
4|
3:
<21,
0,
1> |
@t2 = void ();
5069 58:
6|
3:
<7,
1> |
@t3 = i1;
5070 61:
2|
0:
<65534> | }
5072 112:
0|
1:
<65535,
12,
2> | function void
@f0() {
5074 120:
0|
3:
<1,
4> | blocks
4;
5075 122:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
5076 132:
0|
3:
<1,
0> | i32:
5077 134:
4|
3:
<4,
2> | %c0 = i32
1;
5078 137:
0|
3:
<1,
3> | i1:
5079 139:
4|
3:
<4,
0> | %c1 = i1
0;
5080 142:
0|
0:
<65534> | }
5082 144:
0|
3:
<11,
1,
2,
1> | br i1 %c1, label %b1, label %b2;
5084 148:
0|
3:
<2,
2,
2,
0> | %v0 = add i32 %c0, %c0;
5085 152:
0|
3:
<2,
3,
3,
1> | %v1 = sub i32 %c0, %c0;
5086 156:
0|
3:
<11,
3> | br label %b3;
5088 158:
4|
3:
<2,
4,
4,
2> | %v2 = mul i32 %c0, %c0;
5089 162:
4|
3:
<2,
5,
5,
3> | %v3 = udiv i32 %c0, %c0;
5090 166:
4|
3:
<11,
3> | br label %b3;
5092 169:
0|
3:
<16,
0,
8,
1,
4,
2> | %v4 = phi i32 [%v0, %b1],
5094 174:
4|
3:
<16,
0,
8,
1,
4,
2> | %v5 = phi i32 [%v1, %b1],
5096 180:
0|
3:
<10> | ret void;
5097 181:
6|
0:
<65534> | }
5099 <h3 id=
"select-instruction">Select Instruction
</h3>
5100 <p>The
<em>select
</em> instruction is used to choose between pairs of values, based on a
5101 condition, without PNaClAsm-level branching.
</p>
5102 <p><strong>Syntax
</strong>:
</p>
5103 <pre class=
"prettyprint">
5104 %vN = select CT C, T V1, T V2;
<A
>
5106 <p><strong>Record
</strong>:
</p>
5107 <pre class=
"prettyprint">
5108 AA:
<29, VV1, VV2, CC
>
5110 <p><strong>Semantics
</strong>:
</p>
5111 <p>The
<em>select
</em> instruction chooses pairs of values
<code>V1
</code> and
<code>V2
</code>, based on
5112 condition value
<code>C
</code>. The type
<code>CT
</code> of value
<code>C
</code> must either be an i1, or
5113 a vector of type i1. The type of values
<code>V1
</code> and
<code>V2
</code> must be of type
5114 <code>T
</code>. Type
<code>T
</code> must either be a primitive type, or a vector of a primitive
5116 <p>Both
<code>CT
</code> and
<code>T
</code> must be primitive types, or both must be vector types of
5117 the same size. When the contents of
<code>C
</code> is
1, the corresponding value from
5118 <code>V1
</code> will be chosen. Otherwise the corresponding value from
<code>V2
</code> will be
5120 <p><strong>Constraints
</strong>:
</p>
5121 <pre class=
"prettyprint">
5122 AA == AbbrevIndex(A)
&
5123 CC == RelativeIndex(C)
&
5124 VV1 == RelativeIndex(V1)
&
5125 VV2 == RelativeIndex(V2)
&
5126 T == TypeOf(V1) == TypeOf(V2)
&
5127 UnderlyingType(CT) == i1
&
5128 IsInteger(UnderlyingType(T)) or IsFloat(UnderlyingType(T))
&
5129 UnderlyingCount(C) == UnderlyingCount(T)
&
5132 <p><strong>Updates
</strong>:
</p>
5133 <pre class=
"prettyprint">
5137 <p><strong>Examples
</strong>:
</p>
5138 <pre class=
"prettyprint">
5139 96:
0|
1:
<65535,
12,
2> | function i32
@f0(i32 %p0, i32 %p1) {
5141 104:
0|
3:
<1,
1> | blocks
1;
5142 106:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
5143 116:
0|
3:
<1,
2> | i1:
5144 118:
4|
3:
<4,
3> | %c0 = i1
1;
5145 121:
0|
0:
<65534> | }
5147 124:
0|
3:
<29,
3,
2,
1> | %v0 = select i1 %c0, i32 %p0,
5149 128:
0|
3:
<10,
1> | ret i32 %v0;
5150 130:
4|
0:
<65534> | }
5152 <h3 id=
"call-instructions">Call Instructions
</h3>
5153 <p>The
<em>call
</em> instruction does a function call. The call instruction is used to
5154 cause control flow to transfer to a specified routine, with its incoming
5155 arguments bound to the specified values. When a return instruction in the called
5156 function is reached, control flow continues with the instruction after the
5157 function call. If the call is to a function, the returned value is the value
5158 generated by the call instruction. Otherwise no result is defined by the call.
</p>
5159 <p>If the
<em>tail
</em> flag is associated with the call instruction, then the
<a class=
"reference internal" href=
"/native-client/overview.html#link-for-pnacl-translator"><em>PNaCl
5160 translator
</em></a> is free to perform tail call
5161 optimization. That is, the
<em>tail
</em> flag is a hint that may be ignored by the
5162 PNaCl translator.
</p>
5163 <p>There are two kinds of calls:
<em>direct
</em> and
<em>indirect
</em>. A
<em>direct
</em> call calls a
5164 defined
<a class=
"reference internal" href=
"#link-for-function-address-section"><em>function address
</em></a> (i.e. a
5165 reference to a bitcode ID of the form
<code>%fF
</code>). All other calls are
<em>indirect
</em>.
</p>
5166 <h4 id=
"direct-procedure-call">Direct Procedure Call
</h4>
5167 <p>The direct procedure call calls a defined
<a class=
"reference internal" href=
"#link-for-function-address-section"><em>function
5168 address
</em></a> whose
<a class=
"reference internal" href=
"#link-for-function-type"><em>type
5169 signature
</em></a> returns type void.
</p>
5170 <p><strong>Syntax
</strong>:
</p>
5171 <pre class=
"prettyprint">
5172 TAIL call void
@fF (T1 A1, ... , TN AN);
<A
>
5174 <p><strong>Record
</strong>:
</p>
5175 <pre class=
"prettyprint">
5176 AA:
<34, CC, F, AA1, ... , AAN
>
5178 <p><strong>Semantics
</strong>:
</p>
5179 <p>The direct procedure call calls a define function address
<code>%fF
</code> whose type
5180 signature return type is void. The arguments
<code>A1
</code> through
<code>AN
</code> are passed in
5181 the order specified. The type of argument
<code>AI
</code> must be type
<code>TI
</code> (for all I,
5182 1 <=I
<= N). Flag
<code>TAIL
</code> is optional. If it is included, it must be the
5183 literal
<code>tail
</code>.
</p>
5184 <p>The types of the arguments must match the corresponding types of the function
5185 signature associated with
<code>%fF
</code>. The return type of
<code>%f
</code> must be void.
</p>
5186 <p>TAIL is encoded into calling convention value
<code>CC
</code> as follows:
</p>
5187 <table border=
"1" class=
"docutils">
5190 <thead valign=
"bottom">
5191 <tr class=
"row-odd"><th class=
"head">TAIL
</th>
5192 <th class=
"head">CC
</th>
5195 <tbody valign=
"top">
5196 <tr class=
"row-even"><td>“”</td>
5199 <tr class=
"row-odd"><td>“tail
”</td>
5204 <p><strong>Constraints
</strong>:
</p>
5205 <pre class=
"prettyprint">
5206 AA == AbbrevIndex(A)
&
5208 TypeOfFcn(%fF) == void (T1, ... , TN)
&
5209 TypeOf(AI) == TI for all I,
1 <= I
<= N
5211 <p><strong>Updates
</strong>:
</p>
5212 <pre class=
"prettyprint">
5215 <p><strong>Examples
</strong>:
</p>
5216 <pre class=
"prettyprint">
5217 72:
0|
3:
<8,
3,
0,
1,
0> | declare external
5218 | | void
@f0(i32, i64, i32);
5220 116:
0|
1:
<65535,
12,
2> | function void
@f1(i32 %p0) {
5222 124:
0|
3:
<1,
1> | blocks
1;
5223 126:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
5224 136:
0|
3:
<1,
2> | i64:
5225 138:
4|
3:
<4,
2> | %c0 = i64
1;
5226 141:
0|
0:
<65534> | }
5228 144:
0|
3:
<34,
0,
4,
2,
1,
2> | call void
5229 | |
@f0(i32 %p0, i64 %c0, i32 %p0);
5230 150:
2|
3:
<10> | ret void;
5231 152:
0|
0:
<65534> | }
5233 <h4 id=
"direct-function-call">Direct Function Call
</h4>
5234 <p>The direct function call calls a defined function address whose type signature
5235 returns a value.
</p>
5236 <p><strong>Syntax
</strong>:
</p>
5237 <pre class=
"prettyprint">
5238 %vN = TAIL call RT %fF (T1 A1, ... , TM AM);
<A
>
5240 <p><strong>Record
</strong>:
</p>
5241 <pre class=
"prettyprint">
5242 AA:
<34, CC, F, AA1, ... , AAM
>
5244 <p><strong>Semantics
</strong>:
</p>
5245 <p>The direct function call calls a defined function address
<code>%fF
</code> whose type
5246 signature returned is not type void. The arguments
<code>A1
</code> through
<code>AM
</code> are
5247 passed in the order specified. The type of argument
<code>AI
</code> must be type
<code>TI
</code>
5248 (for all I,
1 <= I
<= N). Flag
<code>TAIL
</code> is optional. If it is included, it must
5249 be the literal
<code>tail
</code>.
</p>
5250 <p>The types of the arguments must match the corresponding types of the function
5251 signature associated with
<code>%fF
</code>. The return type must match
<code>RT
</code>.
</p>
5252 <p>Each parameter type
<code>TI
</code>, and return type
<code>RT
</code>, must either be a primitive
5253 type, or a vector type. If the parameter type is an integer type, it must
5254 either be i32 or i64.
</p>
5255 <p>TAIL is encoded into calling convention value
<code>CC
</code> as follows:
</p>
5256 <table border=
"1" class=
"docutils">
5259 <thead valign=
"bottom">
5260 <tr class=
"row-odd"><th class=
"head">TAIL
</th>
5261 <th class=
"head">CC
</th>
5264 <tbody valign=
"top">
5265 <tr class=
"row-even"><td>“”</td>
5268 <tr class=
"row-odd"><td>“tail
”</td>
5273 <p><strong>Constraints
</strong>:
</p>
5274 <pre class=
"prettyprint">
5275 AA == AbbrevIndex(A)
&
5277 TypeOfFcn(%fF) == RT (T1, ... , TN)
&
5278 TypeOf(AI) == TI for all I,
1 <= I
<= M
&
5279 IsFcnArgType(TI) for all I,
1 <= I
<= M
&
5280 IsFcnArgType(RT)
&
5283 <p><strong>Updates
</strong>:
</p>
5284 <pre class=
"prettyprint">
5288 <p><strong>Examples
</strong>:
</p>
5289 <pre class=
"prettyprint">
5290 72:
0|
3:
<8,
2,
0,
1,
0> | declare external
5291 | | i32
@f0(i32, i64, i32);
5293 116:
0|
1:
<65535,
12,
2> | function i32
@f1(i32 %p0) {
5295 124:
0|
3:
<1,
1> | blocks
1;
5296 126:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
5297 136:
0|
3:
<1,
1> | i64:
5298 138:
4|
3:
<4,
2> | %c0 = i64
1;
5299 141:
0|
0:
<65534> | }
5301 144:
0|
3:
<34,
0,
4,
2,
1,
2> | %v0 = call i32
5302 | |
@f0(i32 %p0, i64 %c0, i32 %p0);
5303 150:
2|
3:
<34,
1,
4,
1> | %v1 = tail call i32
@f1(i32 %v0);
5304 155:
0|
3:
<10,
2> | ret i32 %v0;
5305 157:
4|
0:
<65534> | }
5307 <h4 id=
"indirect-procedure-call">Indirect Procedure Call
</h4>
5308 <p>The indirect procedure call calls a function using an indirect function address,
5309 and whose type signature is assumed to return type void. It is different from
5310 the direct procedure call because we can
’t use the type signature of the
5311 corresponding direct function address to type check the construct.
</p>
5312 <p><strong>Syntax
</strong>:
</p>
5313 <pre class=
"prettyprint">
5314 TAIL call void V (T1 A1, ... , TN AN);
<A
>
5316 <p><strong>Record
</strong>:
</p>
5317 <pre class=
"prettyprint">
5318 AA:
<44, CC, TV, VV, AA1, ... , AAN
>
5320 <p><strong>Semantics
</strong>:
</p>
5321 <p>The indirect call procedure calls a function using value
<code>V
</code> that is an
5322 indirect function address, and whose type signature is assumed to return type
5323 void. The arguments
<code>A1
</code> through
<code>AN
</code> are passed in the order
5324 specified. The type of argument
<code>AI
</code> must be type
<code>TI
</code> (for all I,
1 <= I
<=
5325 N). Flag
<code>TAIL
</code> is optional. If it is included, it must be the literal
5326 <code>tail
</code>.
</p>
5327 <p>Each parameter type
<code>TI
</code> (
1 <= I
<= N) must either be a primitive type, or a
5328 vector type. If the parameter type is an integer type, it must either be i32
5330 <p>TAIL is encoded into calling convention value
<code>CC
</code> as follows:
</p>
5331 <table border=
"1" class=
"docutils">
5334 <thead valign=
"bottom">
5335 <tr class=
"row-odd"><th class=
"head">TAIL
</th>
5336 <th class=
"head">CC
</th>
5339 <tbody valign=
"top">
5340 <tr class=
"row-even"><td>“”</td>
5343 <tr class=
"row-odd"><td>“tail
”</td>
5348 <p>The type signature of the called procedure is assumed to be:
</p>
5349 <pre class=
"prettyprint">
5352 <p>It isn
’t necessary to define this type in the
<a class=
"reference internal" href=
"#link-for-types-block-section"><em>types
5353 block
</em></a>, since the type is inferred rather than
5355 <p><strong>Constraints
</strong>:
</p>
5356 <pre class=
"prettyprint">
5357 AA == AbbrevIndex(A)
&
5359 TV = TypeID(void)
&
5360 AbsoluteIndex(V)
>= NumFuncAddresses
&
5361 TypeOf(AI) == TI for all I,
1 <= I
<= N
&
5362 IsFcnArgType(TI) for all I,
1 <= I
<= N
5364 <p><strong>Updates
</strong>:
</p>
5365 <pre class=
"prettyprint">
5368 <p><strong>Examples
</strong>:
</p>
5369 <pre class=
"prettyprint">
5370 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
5371 48:
0|
3:
<1,
3> | count
3;
5372 50:
4|
3:
<2> |
@t0 = void;
5373 52:
2|
3:
<7,
32> |
@t1 = i32;
5374 55:
4|
3:
<21,
0,
0,
1> |
@t2 = void (i32);
5375 59:
4|
0:
<65534> | }
5377 92:
0|
1:
<65535,
12,
2> | function void
@f0(i32 %p0) {
5379 100:
0|
3:
<1,
1> | blocks
1;
5380 102:
4|
1:
<65535,
11,
2> | constants { // BlockID =
11
5381 112:
0|
3:
<1,
1> | i32:
5382 114:
4|
3:
<4,
2> | %c0 = i32
1;
5383 117:
0|
0:
<65534> | }
5385 120:
0|
3:
<44,
0,
2,
0,
1> | call void %p0(i32 %c0);
5386 125:
4|
3:
<10> | ret void;
5387 127:
2|
0:
<65534> | }
5389 <h4 id=
"indirect-function-call">Indirect Function Call
</h4>
5390 <p>The indirect function call calls a function using a value that is an indirect
5391 function address. It is different from the direct function call because we can
’t
5392 use the type signature of the corresponding literal function address to type
5393 check the construct.
</p>
5394 <p><strong>Syntax
</strong>:
</p>
5395 <pre class=
"prettyprint">
5396 %vN = TAIL call RT V (T1 A1, ... , TM AM);
<A
>
5398 <p><strong>Record
</strong>:
</p>
5399 <pre class=
"prettyprint">
5400 AA:
<34, CC, RRT, VV, AA1, ... , AAM
>
5402 <p><strong>Semantics
</strong>:
</p>
5403 <p>The indirect function call calls a function using a value
<code>V
</code> that is an
5404 indirect function address, and is assumed to return type
<code>RT
</code>. The arguments
5405 <code>A1
</code> through
<code>AM
</code> are passed in the order specified. The type of argument
5406 <code>AI
</code> must be type
<code>TI
</code> (for all I,
1 <= I
<= N). Flag
<code>TAIL
</code> is
5407 optional. If it is included, it must be the literal
<code>tail
</code>.
</p>
5408 <p>Each parameter type
<code>TI
</code> (
1 <= I
<= M), and return type
<code>RT
</code>, must either be
5409 a primitive type, or a vector type. If the parameter type is an integer type,
5410 it must either be i32 or i64.
</p>
5411 <p>TAIL is encoded into calling convention value
<code>CC
</code> as follows:
</p>
5412 <table border=
"1" class=
"docutils">
5415 <thead valign=
"bottom">
5416 <tr class=
"row-odd"><th class=
"head">TAIL
</th>
5417 <th class=
"head">CC
</th>
5420 <tbody valign=
"top">
5421 <tr class=
"row-even"><td>‘’</td>
5424 <tr class=
"row-odd"><td>‘tail
’</td>
5429 <p>The type signature of the called function is assumed to be:
</p>
5430 <pre class=
"prettyprint">
5433 <p>It isn
’t necessary to define this type in the
<a class=
"reference internal" href=
"#link-for-types-block-section"><em>types
5434 block
</em></a>, since the type is inferred rather than
5436 <p><strong>Constraints
</strong>:
</p>
5437 <pre class=
"prettyprint">
5438 AA == AbbrevIndex(A)
&
5439 RRT = TypeID(RT)
&
5440 VV = RelativeIndex(V)
&
5442 AbsoluteIndex(V)
>= NumFcnAddresses
&
5443 TypeOf(AI) == TI for all I,
1 <= I
<= M
&
5444 IsFcnArgType(TI) for all I,
1 <= I
<= M
&
5445 IsFcnArgType(RT)
&
5448 <p><strong>Updates
</strong>:
</p>
5449 <pre class=
"prettyprint">
5453 <p><strong>Examples
</strong>:
</p>
5454 <pre class=
"prettyprint">
5455 40:
0|
1:
<65535,
17,
2> | types { // BlockID =
17
5456 48:
0|
3:
<1,
6> | count
6;
5457 50:
4|
3:
<7,
32> |
@t0 = i32;
5458 53:
6|
3:
<3> |
@t1 = float;
5459 55:
4|
3:
<4> |
@t2 = double;
5460 57:
2|
3:
<21,
0,
0,
0,
1,
2> |
@t3 = i32 (i32, float, double);
5461 62:
6|
3:
<21,
0,
0,
1,
2> |
@t4 = i32 (float, double);
5462 67:
4|
3:
<2> |
@t5 = void;
5463 69:
2|
0:
<65534> | }
5465 104:
0|
1:
<65535,
12,
2> | function
5467 | |
@f0(i32 %p0, float %p1,
5470 112:
0|
3:
<1,
1> | blocks
1;
5472 114:
4|
3:
<44,
0,
3,
0,
2,
1> | %v0 = call i32
5473 | | %p0(float %p1, double %p2);
5474 120:
6|
3:
<10,
1> | ret i32 %v0;
5475 123:
2|
0:
<65534> | }
5477 <h2 id=
"memory-blocks-and-alignment"><span id=
"link-for-memory-blocks-and-alignment-section"></span>Memory Blocks and Alignment
</h2>
5478 <p>In general, variable and heap allocated data are represented as byte addressable
5479 memory blocks. Alignment is always a power of
2, and defines an expectation on
5480 the memory address. That is, an alignment is met if the memory address is
5481 (evenly) divisible by the alignment. Note that alignment of
0 is never allowed.
</p>
5483 <div>Alignment plays a role at two points:
</div></blockquote>
5484 <ul class=
"small-gap">
5485 <li>When you create a local/global variable
</li>
5486 <li>When you load/store data using a pointer.
</li>
5488 <p>PNaClAsm allows most types to be placed at any address, and therefore can
5489 have alignment of
1. However, many architectures can load more efficiently
5490 if the data has an alignment that is larger than
1. As such, choosing a larger
5491 alignment can make load/stores more efficient.
</p>
5492 <p>On loads and stores, the alignment in the instruction is used to communicate
5493 what assumptions the
<a class=
"reference internal" href=
"/native-client/overview.html#link-for-pnacl-translator"><em>PNaCl translator
</em></a> can
5494 make when choosing the appropriate machine instructions. If the alignment is
1,
5495 it can
’t assume anything about the memory address used by the instruction. When
5496 the alignment is greater than one, it can use that information to potentially
5497 chose a more efficient sequence of instructions to do the load/store.
</p>
5498 <p>When laying out data within a variable, one also considers alignment. The reason
5499 for this is that if you want an address to be aligned, within the bytes defining
5500 the variable, you must choose an alignment for the variable that guarantees that
5502 <p>In PNaClAsm, the valid load/store alignments are:
</p>
5503 <table border=
"1" class=
"docutils">
5506 <thead valign=
"bottom">
5507 <tr class=
"row-odd"><th class=
"head">Type
</th>
5508 <th class=
"head">Alignment
</th>
5511 <tbody valign=
"top">
5512 <tr class=
"row-even"><td>i1
</td>
5515 <tr class=
"row-odd"><td>i8
</td>
5518 <tr class=
"row-even"><td>i16
</td>
5521 <tr class=
"row-odd"><td>i32
</td>
5524 <tr class=
"row-even"><td>i64
</td>
5527 <tr class=
"row-odd"><td>Float
</td>
5530 <tr class=
"row-even"><td>Double
</td>
5533 <tr class=
"row-odd"><td><4 x i1
></td>
5534 <td>not applicable
</td>
5536 <tr class=
"row-even"><td><8 x i1
></td>
5537 <td>not applicable
</td>
5539 <tr class=
"row-odd"><td><16 x i1
></td>
5540 <td>not applicable
</td>
5542 <tr class=
"row-even"><td><16 x i8
></td>
5545 <tr class=
"row-odd"><td><8 x i16
></td>
5548 <tr class=
"row-even"><td><4 x i32
></td>
5551 <tr class=
"row-odd"><td><4 x float
></td>
5556 <p>Note that only vectors do not have an alignment value of
1. Hence, they can
’t be
5557 placed at an arbitrary memory address. Also, since vectors on
<code>i1
</code> can
’t be
5558 loaded/stored, the alignment is not applicable for these types.
</p>
5559 <h2 id=
"intrinsic-functions"><span id=
"link-for-intrinsic-functions-section"></span>Intrinsic Functions
</h2>
5560 <p>Intrinsic functions are special in PNaClAsm. They are implemented as specially
5561 named (external) function calls. The purpose of these intrinsic functions is to
5562 extend the PNaClAsm instruction set with additional functionality that is
5563 architecture specific. Hence, they either can
’t be implemented within PNaClAsm,
5564 or a non-architecture specific implementation may be too slow on some
5565 architectures. In such cases, the
<a class=
"reference internal" href=
"/native-client/overview.html#link-for-pnacl-translator"><em>PNaCl
5566 translator
</em></a> must fill in the corresponding
5567 implementation, since only it knows the architecture it is compiling down to.
</p>
5568 <p>Examples of intrinsic function calls are for concurrent operations, atomic
5569 operations, bulk memory moves, thread pointer operations, and long jumps.
</p>
5570 <p>It should be noted that calls to intrinsic functions do not have the same
5571 calling type constraints as ordinary functions. That is, an intrinsic can use
5572 any integer type for arguments/results, unlike ordinary functions (which
5573 restrict integer types to
<code>i32
</code> and
<code>i64
</code>).
</p>
5574 <p>See the
<a class=
"reference internal" href=
"/native-client/reference/pnacl-bitcode-abi.html"><em>PNaCl bitcode reference manual
</em></a> for the full
5575 set of intrinsic functions allowed. Note that in PNaClAsm, all pointer types to
5576 an (LLVM) intrinsic function is converted to type i32.
</p>
5577 <h2 id=
"support-functions"><span id=
"link-for-support-functions-section"></span>Support Functions
</h2>
5578 <p>Defines functions used to convert syntactic representation to values in the
5579 corresponding record.
</p>
5580 <h3 id=
"signrotate">SignRotate
</h3>
5581 <p>The SignRotate function encodes a signed integer in an easily compressible
5582 form. This is done by rotating the sign bit to the rightmost bit, rather than
5583 the leftmost bit. By doing this rotation, both small positive and negative
5584 integers are small (unsigned) integers. Therefore, all small integers can be
5585 encoded as a small (unsigned) integers.
</p>
5586 <p>The definition of SignRotate(N) is:
</p>
5587 <table border=
"1" class=
"docutils">
5590 <thead valign=
"bottom">
5591 <tr class=
"row-odd"><th class=
"head">Argument
</th>
5592 <th class=
"head">Value
</th>
5593 <th class=
"head">Condition
</th>
5596 <tbody valign=
"top">
5597 <tr class=
"row-even"><td>N
</td>
5598 <td>abs(N)
<<1</td>
5601 <tr class=
"row-odd"><td>N
</td>
5602 <td>abs(N)
<<1 +
1</td>
5607 <h3 id=
"absoluteindex"><span id=
"link-for-absolute-index-section"></span>AbsoluteIndex
</h3>
5608 <p>Bitcode IDs of the forms
<code>@fN
</code>,
<code>@gN
</code>,
<code>%pN
</code>,
<code>%cN
</code>, and
<code>%vN
</code>, are
5609 combined into a single index space. This can be done because of the ordering
5610 imposed by PNaClAsm. All function address bitcode IDs must be defined before any
5611 of the other forms of bitcode IDs. All global address bitcode IDs must be
5612 defined before any local bitcode IDs. Within a function block, the parameter
5613 bitcode IDs must be defined before constant IDs, and constant IDs must be
5614 defined before instruction value IDs.
</p>
5615 <p>Hence, within a function block, it is safe to refer to all of these
5616 bitcode IDs using a single
<em>absolute
</em> index. The absolute index for
5617 each kind of bitcode ID is computed as follows:
</p>
5618 <table border=
"1" class=
"docutils">
5621 <thead valign=
"bottom">
5622 <tr class=
"row-odd"><th class=
"head">Bitcode ID
</th>
5623 <th class=
"head">AbsoluteIndex
</th>
5626 <tbody valign=
"top">
5627 <tr class=
"row-even"><td>@tN
</td>
5630 <tr class=
"row-odd"><td>@fN
</td>
5633 <tr class=
"row-even"><td>@gN
</td>
5634 <td>N + NumFcnAddresses
</td>
5636 <tr class=
"row-odd"><td>@pN
</td>
5637 <td>N + NumFcnAddresses + NumGlobalAddresses
</td>
5639 <tr class=
"row-even"><td>@cN
</td>
5640 <td>N + NumFcnAddresses + NumGlobalAddresses + NumParams
</td>
5642 <tr class=
"row-odd"><td>@vN
</td>
5643 <td>N + NumFcnAddresses + NumGlobalAddresses + NumParams + NumFcnConsts
</td>
5647 <h3 id=
"relativeindex"><span id=
"link-for-relative-index"></span>RelativeIndex
</h3>
5648 <p>Relative indices are used to refer to values within instructions of a function.
5649 The relative index of an ID is always defined in terms of the index associated
5650 with the next value generating instruction. It is defined as follows:
</p>
5651 <pre class=
"prettyprint">
5652 RelativeIndex(J) = AbsoluteIndex(%vN) - AbsoluteIndex(J)
5655 <pre class=
"prettyprint">
5658 <h3 id=
"abbrevindex">AbbrevIndex
</h3>
5659 <p>This function converts user-defined abbreviation indices to the corresponding
5660 internal abbreviation index saved in the bitcode file. It adds
4 to its
5661 argument, since there are
4 predefined internal abbreviation indices (
0,
1,
2,
5663 <table border=
"1" class=
"docutils">
5666 <thead valign=
"bottom">
5667 <tr class=
"row-odd"><th class=
"head">N
</th>
5668 <th class=
"head">AbbrevIndex(N)
</th>
5671 <tbody valign=
"top">
5672 <tr class=
"row-even"><td>undefined
</td>
5675 <tr class=
"row-odd"><td>%aA
</td>
5678 <tr class=
"row-even"><td>@aA
</td>
5683 <h3 id=
"log2">Log2
</h3>
5684 <p>This is the
32-bit log2 value of its argument.
</p>
5685 <h3 id=
"bitsizeof">BitSizeOf
</h3>
5686 <p>Returns the number of bits needed to represent its argument (a type).
</p>
5687 <table border=
"1" class=
"docutils">
5690 <thead valign=
"bottom">
5691 <tr class=
"row-odd"><th class=
"head">T
</th>
5692 <th class=
"head">BitSizeOf
</th>
5695 <tbody valign=
"top">
5696 <tr class=
"row-even"><td>i1
</td>
5699 <tr class=
"row-odd"><td>i8
</td>
5702 <tr class=
"row-even"><td>i16
</td>
5705 <tr class=
"row-odd"><td>i32
</td>
5708 <tr class=
"row-even"><td>i64
</td>
5711 <tr class=
"row-odd"><td>float
</td>
5714 <tr class=
"row-even"><td>double
</td>
5717 <tr class=
"row-odd"><td><N X T
></td>
5718 <td>N * BitSizeOf(T)
</td>
5722 <h3 id=
"underlyingtype">UnderlyingType
</h3>
5723 <p>Returns the primitive type of the type construct. For primitive types, the
5724 <em>UnderlyingType
</em> is itself. For vector types, the base type of the vector is the
5725 underlying type.
</p>
5726 <h3 id=
"underlyingcount">UnderlyingCount
</h3>
5727 <p>Returns the size of the vector if given a vector, and
0 for primitive types.
5728 Note that this function is used to check if two vectors are of the same size.
5729 It is also used to test if two types are either primitive (i.e. UnderlyingCount
5730 returns
0 for both types) or are vectors of the same size (i.e. UnderlyingCount
5731 returns the same non-zero value).
</p>
5732 <h3 id=
"isinteger">IsInteger
</h3>
5733 <p>Returns true if the argument is in {i1, i8, i16, i32, i64}.
</p>
5734 <h3 id=
"isfloat">IsFloat
</h3>
5735 <p>Returns true if the argument is in {
<code>float
</code>,
<code>double
</code>}.
</p>
5736 <h3 id=
"isvector">IsVector
</h3>
5737 <p>Returns true if the argument is a vector type.
</p>
5738 <h3 id=
"isprimitive">IsPrimitive
</h3>
5739 <p>Returns true if the argument is a primitive type. That is:
</p>
5740 <pre class=
"prettyprint">
5741 IsPrimitive(T) == IsInteger(T) or IsFloat(T)
5743 <h3 id=
"isfcnargtype">IsFcnArgType
</h3>
5744 <p>Returns true if the argument is a primitive type or a vector type. Further,
5745 if it is an integer type, it must be i32 or i64. That is:
</p>
5746 <pre class=
"prettyprint">
5747 IsFcnArgType(T) = (IsInteger(T) and (i32 = BitSizeOf(T)
5748 or i64 == BitSizeOf(T)))
5749 or IsFloat(T) or IsVector(T)
5751 <h2 id=
"abbreviations"><span id=
"link-for-abbreviations-section"></span>Abbreviations
</h2>
5752 <p>Abbreviations are used to convert PNaCl records to a sequence of bits. PNaCl
5753 uses the same strategy as
<a class=
"reference external" href=
"http://llvm.org/docs/BitCodeFormat.html">LLVM
’s bitcode file format
</a>. See that document for more
5755 <p>It should be noted that we replace LLVM
’s header (called the
<em>Bitcode Wrapper
5756 Format
</em>) with the bytes of the
<a class=
"reference internal" href=
"#link-for-header-record-section"><em>PNaCl record
5757 header
</em></a>. In addition, PNaCl bitcode files do
5758 not allow
<em>blob
</em> abbreviation.
</p>
5759 <h3 id=
"abbreviations-block"><span id=
"link-for-abbreviations-block-section"></span>Abbreviations Block
</h3>
5760 <p>The abbreviations block is the first block in the module build. The
5761 block is divided into sections. Each section is a sequence of records. Each
5762 record in the sequence defines a user-defined abbreviation. Each section
5763 defines abbreviations that can be applied to all (succeeding) blocks of a
5764 particular kind. These abbreviations are denoted by the (global) ID of the form
5765 <em>@aN
</em>.
</p>
5766 <p>In terms of
<a class=
"reference external" href=
"http://llvm.org/docs/BitCodeFormat.html">LLVM
’s bitcode file format
</a>, the abbreviations block is called a
5767 <em>BLOCKINFO
</em> block. Records
<em>SETBID
</em> and
<em>DEFINE_ABBREV
</em> are the only records
5768 allowed in PNaCl
’s abbreviation block (i.e. it doesn
’t allow
<em>BLOCKNAME
</em> and
5769 <em>SETRECORDNAME
</em> records).
</p>
5770 <h3 id=
"todo">TODO
</h3>
5771 <p>Extend this document to describe PNaCl
’s bitcode bit sequencer
5772 without requiring the reader to refer to
<a class=
"reference external" href=
"http://llvm.org/docs/BitCodeFormat.html">LLVM
’s bitcode file
5776 {{/partials.standard_nacl_article}}