| OLD | NEW |
|---|
| (Empty) | |
| 1 {{+bindTo:partials.standard_nacl_article}} |
| 2 |
| 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"> |
| 6 <ul class="small-gap"> |
| 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">Defaul
t Abbreviations</a></li> |
| 12 <li><a class="reference internal" href="#pnacl-identifiers" id="id11">PNaCl Iden
tifiers</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 Func
tions</a></li> |
| 19 <li><a class="reference internal" href="#link-to-id-counters" id="id17">ID Count
ers</a></li> |
| 20 <li><a class="reference internal" href="#size-variables" id="id18">Size Variable
s</a></li> |
| 21 <li><a class="reference internal" href="#other-variables" id="id19">Other Variab
les</a></li> |
| 22 </ul> |
| 23 </li> |
| 24 <li><p class="first"><a class="reference internal" href="#global-records" id="id
20">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 Blo
ck 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">Abbrevia
tion Record</a></li> |
| 30 </ul> |
| 31 </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-B
it Floating Point Type</a></li> |
| 38 <li><a class="reference internal" href="#id1" id="id30">64-bit Floating Point Ty
pe</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> |
| 41 </ul> |
| 42 </li> |
| 43 <li><p class="first"><a class="reference internal" href="#globals-block" id="id3
3">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">Gl
obal Variable Addresses</a></li> |
| 47 <li><a class="reference internal" href="#global-constant-addresses" id="id36">Gl
obal Constant Addresses</a></li> |
| 48 <li><a class="reference internal" href="#zerofill-initializer" id="id37">Zerofil
l Initializer</a></li> |
| 49 <li><a class="reference internal" href="#data-initializer" id="id38">Data Initia
lizer</a></li> |
| 50 <li><a class="reference internal" href="#relocation-initializer" id="id39">Reloc
ation Initializer</a></li> |
| 51 <li><a class="reference internal" href="#subfield-relocation-initializer" id="id
40">Subfield Relocation Initializer</a></li> |
| 52 <li><a class="reference internal" href="#compound-initializer" id="id41">Compoun
d Initializer</a></li> |
| 53 </ul> |
| 54 </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> |
| 58 </ul> |
| 59 </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 Recor
d</a></li> |
| 63 <li><a class="reference internal" href="#function-address" id="id46">Function Ad
dress</a></li> |
| 64 </ul> |
| 65 </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 Rec
ord</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 Lite
ral</a></li> |
| 71 <li><a class="reference internal" href="#floating-point-literal" id="id51">Float
ing Point Literal</a></li> |
| 72 </ul> |
| 73 </li> |
| 74 <li><p class="first"><a class="reference internal" href="#function-blocks" id="i
d52">Function Blocks</a></p> |
| 75 <ul class="small-gap"> |
| 76 <li><a class="reference internal" href="#function-enter" id="id53">Function Ente
r</a></li> |
| 77 <li><a class="reference internal" href="#link-for-basic-blocks-count" id="id54">
Count Record</a></li> |
| 78 </ul> |
| 79 </li> |
| 80 <li><p class="first"><a class="reference internal" href="#terminator-instruction
s" id="id55">Terminator Instructions</a></p> |
| 81 <ul class="small-gap"> |
| 82 <li><a class="reference internal" href="#return-void-instruction" id="id56">Retu
rn Void Instruction</a></li> |
| 83 <li><a class="reference internal" href="#return-value-instruction" id="id57">Ret
urn Value Instruction</a></li> |
| 84 <li><a class="reference internal" href="#unconditional-branch-instruction" id="i
d58">Unconditional Branch Instruction</a></li> |
| 85 <li><a class="reference internal" href="#conditional-branch-instruction" id="id5
9">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 In
struction</a></li> |
| 88 </ul> |
| 89 </li> |
| 90 <li><p class="first"><a class="reference internal" href="#integer-binary-instruc
tions" 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 Sub
tract</a></li> |
| 94 <li><a class="reference internal" href="#integer-multiply" id="id65">Integer Mul
tiply</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">Unsi
gned Integer Divide</a></li> |
| 97 <li><a class="reference internal" href="#signed-integer-remainder" id="id68">Sig
ned 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></l
i> |
| 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">Arith
metic 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></l
i> |
| 104 <li><a class="reference internal" href="#logical-xor" id="id75">Logical Xor</a><
/li> |
| 105 </ul> |
| 106 </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">Floa
ting Point Subtract</a></li> |
| 111 <li><a class="reference internal" href="#floating-point-multiply" id="id79">Floa
ting Point Multiply</a></li> |
| 112 <li><a class="reference internal" href="#floating-point-divide" id="id80">Floati
ng Point Divide</a></li> |
| 113 <li><a class="reference internal" href="#floating-point-remainder" id="id81">Flo
ating Point Remainder</a></li> |
| 114 </ul> |
| 115 </li> |
| 116 <li><p class="first"><a class="reference internal" href="#memory-creation-and-ac
cess-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 In
struction</a></li> |
| 119 <li><a class="reference internal" href="#load-instruction" id="id84">Load Instru
ction</a></li> |
| 120 <li><a class="reference internal" href="#store-instruction" id="id85">Store Inst
ruction</a></li> |
| 121 </ul> |
| 122 </li> |
| 123 <li><p class="first"><a class="reference internal" href="#conversion-instruction
s" id="id86">Conversion Instructions</a></p> |
| 124 <ul class="small-gap"> |
| 125 <li><a class="reference internal" href="#integer-truncating-instruction" id="id8
7">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">Z
ero Extending Instruction</a></li> |
| 128 <li><a class="reference internal" href="#sign-extending-instruction" id="id90">S
ign Extending Instruction</a></li> |
| 129 <li><a class="reference internal" href="#floating-point-extending-instruction" i
d="id91">Floating Point Extending Instruction</a></li> |
| 130 <li><a class="reference internal" href="#floating-point-to-unsigned-integer-inst
ruction" id="id92">Floating Point to Unsigned Integer Instruction</a></li> |
| 131 <li><a class="reference internal" href="#floating-point-to-signed-integer-instru
ction" id="id93">Floating Point to Signed Integer Instruction</a></li> |
| 132 <li><a class="reference internal" href="#unsigned-integer-to-floating-point-inst
ruction" id="id94">Unsigned Integer to Floating Point Instruction</a></li> |
| 133 <li><a class="reference internal" href="#signed-integer-to-floating-point-instru
ction" 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> |
| 135 </ul> |
| 136 </li> |
| 137 <li><p class="first"><a class="reference internal" href="#comparison-instruction
s" id="id97">Comparison Instructions</a></p> |
| 138 <ul class="small-gap"> |
| 139 <li><a class="reference internal" href="#integer-comparison-instructions" id="id
98">Integer Comparison Instructions</a></li> |
| 140 <li><a class="reference internal" href="#floating-point-comparison-instructions"
id="id99">Floating Point Comparison Instructions</a></li> |
| 141 </ul> |
| 142 </li> |
| 143 <li><p class="first"><a class="reference internal" href="#vector-instructions" i
d="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> |
| 147 </ul> |
| 148 </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">Fo
rward Type Declaration</a></li> |
| 152 <li><a class="reference internal" href="#phi-instruction" id="id105">Phi Instruc
tion</a></li> |
| 153 <li><a class="reference internal" href="#select-instruction" id="id106">Select I
nstruction</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">Direc
t 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">Ind
irect Procedure Call</a></li> |
| 159 <li><a class="reference internal" href="#indirect-function-call" id="id111">Indi
rect Function Call</a></li> |
| 160 </ul> |
| 161 </li> |
| 162 </ul> |
| 163 </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">Intrins
ic 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">UnderlyingTy
pe</a></li> |
| 175 <li><a class="reference internal" href="#underlyingcount" id="id122">UnderlyingC
ount</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> |
| 181 </ul> |
| 182 </li> |
| 183 <li><p class="first"><a class="reference internal" href="#abbreviations" id="id1
28">Abbreviations</a></p> |
| 184 <ul class="small-gap"> |
| 185 <li><a class="reference internal" href="#abbreviations-block" id="id129">Abbrevi
ations Block</a></li> |
| 186 <li><a class="reference internal" href="#todo" id="id130">TODO</a></li> |
| 187 </ul> |
| 188 </li> |
| 189 </ul> |
| 190 |
| 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 inte
rnal" 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>abb
reviations</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 intern
al" 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. Li
ke |
| 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-s
ection"><em>enter</em></a> and |
| 213 <a class="reference internal" href="#link-for-exit-block-record-section"><em>exi
t</em></a> block record.</p> |
| 214 <p>These block records must be used like balanced parentheses to define the bloc
k |
| 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>abbrevi
ations</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. A
ll |
| 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 |
| 233 them.</p> |
| 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 |
| 242 records.</p> |
| 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 |
| 246 possible.</p> |
| 247 <p>On the other hand, when delivering across the web, one may want to compress t
he |
| 248 sequence of bits considerably, to reduce costs in delivering web pages. Note |
| 249 that <a class="reference internal" href="/native-client/devguide/devcycle/buildi
ng.html#pnacl-compress"><em>pnacl-compress</em></a> is provided as part of the S
DK to do |
| 250 this job.</p> |
| 251 <h2 id="data-model">Data Model</h2> |
| 252 <p>The data model for PNaCl bitcode is fixed at little-endian ILP32: pointers ar
e |
| 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 |
| 255 long</code>).</p> |
| 256 <p>Integers are assumed to be modeled using two’s complement. Floating po
int |
| 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> 3
2-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" hr
ef="#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 |
| 268 block.</dd> |
| 269 <dt>Types block</dt> |
| 270 <dd>The <a class="reference internal" href="#link-for-types-block-section"><em>t
ypes 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 global addresses of global variables and constants used by the program. It |
| 277 also defines how each global (associated with the global address) is |
| 278 initialized.</dd> |
| 279 <dt>Valuesymtab block</dt> |
| 280 <dd>The <a class="reference internal" href="#link-for-valuesymtab-block-section"
><em>valuesymtab block</em></a> defines |
| 281 textual names for external function addresses.</dd> |
| 282 <dt>Function block</dt> |
| 283 <dd>Each function (implemented) in a program has its own <a class="reference int
ernal" href="#link-for-function-blocks-section"><em>function |
| 284 block</em></a> that defines the implementation of |
| 285 the corresponding function.</dd> |
| 286 <dt>Constants block</dt> |
| 287 <dd>Each implemented function that uses constants in its instructions defines a |
| 288 <a class="reference internal" href="#link-for-constants-block-section"><em>const
ants block</em></a>. Constants blocks |
| 289 appear within the corresponding function block of the implemented function.</dd> |
| 290 <dt>Abbreviations block</dt> |
| 291 <dd>Defines global abbreviations that are used to compress PNaCl records. The |
| 292 <a class="reference internal" href="#link-for-abbreviations-block-section"><em>a
bbreviations block</em></a> is segmented |
| 293 into multiple sections, one section for each kind of block. This block appears |
| 294 at the beginning of the module block.</dd> |
| 295 </dl> |
| 296 <p>This section is only intended as a high-level discussion of blocks. Later |
| 297 sections will dive more deeply into the constraints on how blocks must be laid |
| 298 out. This section only presents the overall concepts of what kinds of data are |
| 299 stored in each of the blocks.</p> |
| 300 <p>A PNaCl program consists of a <a class="reference internal" href="#link-for-h
eader-record-section"><em>header |
| 301 record</em></a> and a <a class="reference internal" href="#link-for-module-block
"><em>module |
| 302 block</em></a>. The header record defines a sequence of bytes |
| 303 uniquely identifying the file as a bitcode file. The module block defines the |
| 304 program to run.</p> |
| 305 <p>Each block, within a bitcode file, defines values. These values are associate
d |
| 306 with IDs. Each type of block defines different kinds of IDs. The |
| 307 <a class="reference internal" href="#link-for-module-block"><em>module</em></a>, |
| 308 <a class="reference internal" href="#link-for-types-block-section"><em>types</em
></a>, |
| 309 <a class="reference internal" href="#link-for-globals-block-section"><em>globals
</em></a>, and |
| 310 <a class="reference internal" href="#link-for-abbreviations-block-section"><em>a
bbreviations</em></a> blocks define global |
| 311 identifiers, and only a single instance can appear. The |
| 312 <a class="reference internal" href="#link-for-function-blocks-section"><em>funct
ion</em></a> and |
| 313 <a class="reference internal" href="#link-for-constants-block-section"><em>const
ant</em></a> blocks define local |
| 314 identifiers, and can have multiple instances (one for each implemented |
| 315 function).</p> |
| 316 <p>The only records in the module block that define values, are <a class="refere
nce internal" href="#link-for-function-address-section"><em>function |
| 317 address</em></a> records. Each function address |
| 318 record defines a different function address, and the <a class="reference interna
l" href="#link-for-function-type"><em>type |
| 319 signature</em></a> associated with that function address.</p> |
| 320 <p>Each <a class="reference internal" href="#link-for-function-blocks-section"><
em>function block</em></a> defines the |
| 321 implementation of a single function. Each function block defines the |
| 322 intermediate representation of the function, consisting of basic blocks and |
| 323 instructions. If constants are used within instructions, they are defined in a |
| 324 <a class="reference internal" href="#link-for-constants-block-section"><em>const
ants block</em></a>, nested within the |
| 325 corresponding function block.</p> |
| 326 <p>All function blocks are associated with a corresponding function address. Thi
s |
| 327 association is positional rather than explicit. That is, the Nth function block |
| 328 in a module block corresponds to the Nth |
| 329 <a class="reference internal" href="#link-for-function-address-section"><em>defi
ning</em></a> (rather than declared) |
| 330 function address record in the module block.</p> |
| 331 <p>Hence, within a function block, there is no explicit reference to the functio
n |
| 332 address the block defines. For readability, PNaClAsm uses the corresponding |
| 333 function signature, associated with the corresponding function address record, |
| 334 even though that data does not appear in the corresponding records.</p> |
| 335 <h2 id="pnacl-records"><span id="link-for-pnacl-records"></span>PNaCl Records</h
2> |
| 336 <p>A PNaCl record is a non-empty sequence of unsigned, 64-bit, integers. A recor
d |
| 337 is identified by the record <em>code</em>, which is the first element in the |
| 338 sequence. Record codes are unique within a specific kind of block, but are not |
| 339 necessarily unique across different kinds of blocks. The record code acts as the |
| 340 variant discriminator (i.e. tag) within a block, to identify what kind of record |
| 341 it is.</p> |
| 342 <p>Record codes that are local to a specific kind of block are small values |
| 343 (starting from zero). In an ideal world, they would be a consecutive sequence of |
| 344 integers, starting at zero. However, the reality is that PNaCl records evolved |
| 345 over time (and actually started as <a class="reference external" href="http://ll
vm.org/docs/BitCodeFormat.html">LLVM records</a>). For backward compatibility, |
| 346 obsolete numbers have not been reused, leaving gaps in the actual record code |
| 347 values used.</p> |
| 348 <p>Global record codes are record codes that have the same meaning in multiple |
| 349 kinds of blocks. To separate global record codes from local record codes, large |
| 350 values are used. Currently there are four <a class="reference internal" href="#
link-for-global-record-codes"><em>global record |
| 351 codes</em></a>. To make these cases clear, and to leave |
| 352 ample room for future growth in PNaClAsm, these special records have record |
| 353 codes close to the value 2<sup>16</sup>. Note: Well-formed PNaCl bitcode files |
| 354 do not have record codes >= 2<sup>16</sup>.</p> |
| 355 <p>A PNaCl record is denoted as follows:</p> |
| 356 <pre class="prettyprint"> |
| 357 a: <v0, v1, ... , vN> |
| 358 </pre> |
| 359 <p>The value <code>v0</code> is the record code. The remaining values, <code>v1<
/code> through |
| 360 <code>vN</code>, are parameters that fill in additional information needed by th
e |
| 361 construct it represents. All records must have a record code. Hence, empty PNaCl |
| 362 records are not allowed. <code>a</code> is the index to the abbreviation used to
convert |
| 363 the record to a bit sequence.</p> |
| 364 <p>While most records (for a given record code) have the same length, it is not |
| 365 true of all record codes. Some record codes can have arbitrary length. In |
| 366 particular, function type signatures, call instructions, phi nodes, switch |
| 367 instructions, and global variable initialization records all have variable |
| 368 length. The expected length is predefined and part of the PNaClAsm language. See |
| 369 the corresponding construct (associated with the record) to determine the |
| 370 expected length.</p> |
| 371 <p>The <code>PNaCl bitstream writer</code>, which converts records to bit sequen
ces, does |
| 372 this by writing out the abbreviation index used to encode the record, followed |
| 373 by the contents of the record. The details of this are left to the section on |
| 374 <a class="reference internal" href="#link-for-abbreviations-section"><em>abbrevi
ations</em></a>. However, at the record |
| 375 level, one important aspect of this appears in :<a class="reference internal" hr
ef="#link-for-enter-block-record-section"><em>block |
| 376 enter</em></a> records. These records must define |
| 377 how many bits are required to hold abbreviation indices associated with records |
| 378 of that block.</p> |
| 379 <h2 id="default-abbreviations"><span id="link-for-default-abbreviations"></span>
Default Abbreviations</h2> |
| 380 <p>There are 4 predefined (default) abbreviation indices, used as the default |
| 381 abbreviations for PNaCl records. They are:</p> |
| 382 <dl class="docutils"> |
| 383 <dt>0</dt> |
| 384 <dd>Abbreviation index for the abbreviation used to bit-encode an exit block |
| 385 record.</dd> |
| 386 <dt>1</dt> |
| 387 <dd>Abbreviation index for the abbreviation used to bit-encode an enter block |
| 388 record.</dd> |
| 389 <dt>2</dt> |
| 390 <dd>Abbreviation index for the abbreviation used to bit-encode a user-defined |
| 391 abbreviation. Note: User defined abbreviations are also encoded as records, |
| 392 and hence need an abbreviation index to bit-encode them.</dd> |
| 393 <dt>3</dt> |
| 394 <dd>Abbreviation index for the default abbreviation to bit-encode all other |
| 395 records in the bitcode file.</dd> |
| 396 </dl> |
| 397 <p>A block may, in addition, define a list of block specific, user-defined, |
| 398 abbreviations (of length <code>U</code>). The number of bits <code>B</code> spec
ified for an enter |
| 399 record must be sufficiently large such that:</p> |
| 400 <pre class="prettyprint"> |
| 401 2**B >= U + 4 |
| 402 </pre> |
| 403 <p>In addition, the upper limit for <code>B</code> is <code>16</code>.</p> |
| 404 <p>PNaClAsm requires specifying the number of bits needed to read abbreviations
as |
| 405 part of the enter block record. This allows the PNaCl bitcode reader/writer to |
| 406 use the specified number of bits to encode abbreviation indices.</p> |
| 407 <h2 id="pnacl-identifiers">PNaCl Identifiers</h2> |
| 408 <p>A program is defined by a <a class="reference internal" href="#link-for-modul
e-block"><em>module block</em></a>. Blocks can |
| 409 be nested within other blocks, including the module block. Each block defines a |
| 410 sequence of records.</p> |
| 411 <p>Most of the records, within a block, also define unique values. Each unique |
| 412 value is given a corresponding unique identifier (i.e. <em>ID</em>). In PNaClAsm
, each |
| 413 kind of block defines its own kind of identifiers. The names of these |
| 414 identifiers are defined by concatenating a prefix character (<code>'@'</code
> or |
| 415 <code>'%'</code>), the kind of block (a single character), and a suffix index. T
he suffix |
| 416 index is defined by the positional location of the defined value within the |
| 417 records of the corresponding block. The indices are all zero based, meaning that |
| 418 the first defined value (within a block) is defined using index 0.</p> |
| 419 <p>Identifiers are categorized into two types, <em>local</em> and <em>global</em
>. Local |
| 420 identifiers are identifiers that are associated with the implementation of a |
| 421 single function. In that sense, they are local to the block they appear in.</p> |
| 422 <p>All other identifiers are global, and can appear in multiple blocks. This spl
it |
| 423 is intentional. Global identifiers are used by multiple functions, and therefore |
| 424 must be known in all function implementations. Local identifiers only apply to a |
| 425 single function, and can be reused between functions. The <a class="reference i
nternal" href="/native-client/overview.html#link-for-pnacl-translator"><em>PNaCl |
| 426 translator</em></a> uses this separation to parallelize the |
| 427 compilation of functions.</p> |
| 428 <p>Note that local abbreviation identifiers are unique to the block they appear |
| 429 in. Global abbreviation identifiers are only unique to the block type they are |
| 430 defined for. Different block types can reuse global abbreviation identifiers.</p
> |
| 431 <p>Global identifiers use the prefix character <code>'@'</code> while local
identifiers use |
| 432 the prefix character <code>'%'</code>.</p> |
| 433 <p>Note that by using positional location to define identifiers (within a block)
, |
| 434 the values defined in PNaCl bitcode files need not be explicitly included in the |
| 435 bitcode file. Rather, they are inferred by the (ordered) position of the record |
| 436 in the block. This is also intentional. It is used to reduce the amount of data |
| 437 that must be (explicitly) passed to the <a class="reference internal" href="/nat
ive-client/overview.html#link-for-pnacl-translator"><em>PNaCl |
| 438 translator</em></a>, and downloaded from the cloud.</p> |
| 439 <p>In general, most of the records within blocks are assumed to be topologically |
| 440 sorted, putting value definitions before their uses. This implies that records |
| 441 do not need to encode data if they can deduce the corresponding information from |
| 442 their uses.</p> |
| 443 <p>The most common use of this is that many instructions use the type of their |
| 444 operands to determine the type of the instruction. Again, this is |
| 445 intentional. It allows less information to be stored.</p> |
| 446 <p>However, for function blocks (which define instructions), a topological sort
may |
| 447 not exist. Loop carried value dependencies simply do not allow topologically |
| 448 sorting. To deal with this, function blocks have a notion of (instruction value) |
| 449 <a class="reference internal" href="#link-for-forward-type-declaration-section">
<em>forward type |
| 450 declarations</em></a>. These declarations |
| 451 must appear before any of the uses of that value, if the (instruction) value is |
| 452 defined later in the function than its first use.</p> |
| 453 <p>The kinds of identifiers used in PNaClAsm are:</p> |
| 454 <dl class="docutils"> |
| 455 <dt>@a</dt> |
| 456 <dd>Global abbreviation identifier.</dd> |
| 457 <dt>%a</dt> |
| 458 <dd>Local abbreviation identifier.</dd> |
| 459 <dt>%b</dt> |
| 460 <dd>Function basic block identifier.</dd> |
| 461 <dt>%c</dt> |
| 462 <dd>Function constant identifier.</dd> |
| 463 <dt>@f</dt> |
| 464 <dd>Global function address identifier.</dd> |
| 465 <dt>@g</dt> |
| 466 <dd>Global variable/constant address identifier.</dd> |
| 467 <dt>%p</dt> |
| 468 <dd>Function parameter identifier.</dd> |
| 469 <dt>@t</dt> |
| 470 <dd>Global type identifier.</dd> |
| 471 <dt>%v</dt> |
| 472 <dd>Value generated by an instruction in a function block.</dd> |
| 473 </dl> |
| 474 <h2 id="conventions-for-describing-records">Conventions For Describing Records</
h2> |
| 475 <p>PNaClAsm is the textual representation of <a class="reference internal" href=
"#link-for-pnacl-records"><em>PNaCl |
| 476 records</em></a>. Each PNaCl record is described by a |
| 477 corresponding PNaClAsm construct. These constructs are described using syntax |
| 478 rules, and semantics on how they are converted to records. Along with the rules, |
| 479 is a notion of <a class="reference internal" href="#link-for-global-state-sectio
n"><em>global state</em></a>. The global |
| 480 state is updated by syntax rules. The purpose of the global state is to track |
| 481 positional dependencies between records.</p> |
| 482 <p>For each PNaCl construct, we define multiple subsections. The <strong>Syntax<
/strong> |
| 483 subsection defines a syntax rule for the construct. The <strong>Record</strong>
subsection |
| 484 defines the corresponding record associated with the syntax rule. The |
| 485 <strong>Semantics</strong> subsection describes the semantics associated with th
e record, in |
| 486 terms of data within the global state and the corresponding syntax. It also |
| 487 includes other high-level semantics, when appropriate.</p> |
| 488 <p>The <strong>Constraints</strong> subsection (if present) defines any constrai
nts associated |
| 489 with the construct, including the global state. The <strong>Updates</strong> sub
section (if |
| 490 present) defines how the global state is updated when the construct is |
| 491 processed. The <strong>Examples</strong> subsection gives one or more examples
of using the |
| 492 corresponding PNaClAsm construct.</p> |
| 493 <p>Some semantics subsections use functions to compute values. The meaning of |
| 494 functions can be found in <a class="reference internal" href="#link-for-support-
functions-section"><em>support |
| 495 functions</em></a>.</p> |
| 496 <p>The syntax rule may include the |
| 497 <a class="reference internal" href="#link-for-abbreviations-section"><em>abbrevi
ation</em></a> to use, when converting to a |
| 498 bit-sequence. These abbreviations, if allowed, are at the end of the construct, |
| 499 and enclosed in <code><</code> and <code>></code> brackets. These abbrevia
tions are optional in |
| 500 the syntax, and can be omitted. If they are used, the abbreviation brackets are |
| 501 part of the actual syntax of the construct. If the abbreviation is omitted, the |
| 502 default abbreviation index is used. To make it clear that abbreviations are |
| 503 optional, syntax rules separate abbreviations using plenty of whitespace.</p> |
| 504 <p>Within a syntax rule, lower case characters are literal values. Sequences of |
| 505 upper case alphanumeric characters are named values. If we mix lower and upper |
| 506 case letters within a name appearing in a syntax rule, the lower case letters |
| 507 are literal while the upper case sequence of alphanumeric characters denote rule |
| 508 specific values. The valid values for each of these names will be defined in |
| 509 the corresponding semantics and constraints subsections.</p> |
| 510 <p>For example, consider the following syntax rule:</p> |
| 511 <pre class="prettyprint"> |
| 512 %vN = add T O1, O2; <A> |
| 513 </pre> |
| 514 <p>This rule defines a PNaClAsm add instruction. This construct defines an |
| 515 instruction that adds two values (<code>O1</code> and <code>O2</code>) to genera
te instruction |
| 516 value <code>%vN</code>. The types of the arguments, and the result, are all of t
ype |
| 517 <code>T</code>. If abbreviation ID <code>A</code> is present, the record is enco
ded using that |
| 518 abbreviation. Otherwise the corresponding default abbreviation (3) is used.</p> |
| 519 <p>To be concrete, the syntactic rule above defines the structure of the followi
ng |
| 520 PNaClAsm examples:</p> |
| 521 <pre class="prettyprint"> |
| 522 %v10 = add i32 %v1, %v2; <@a5> |
| 523 %v11 = add i32 %v10, %v3; |
| 524 </pre> |
| 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 identifer 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"> |
| 536 int fact(int n) { |
| 537 if (n == 1) return 1; |
| 538 return n * fact(n-1); |
| 539 } |
| 540 </pre> |
| 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/bui
lding.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 |
| 546 | 0> | |
| 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"; |
| 564 | 116> | |
| 565 96:4| 0: <65534> | } |
| 566 100:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0) { |
| 567 | | // BlockID = 12 |
| 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> | } |
| 573 | | %b0: |
| 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; |
| 576 | | %b1: |
| 577 136:6| 3: <10, 2> | ret i32 %c0; |
| 578 | | %b2: |
| 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> |} |
| 585 </pre> |
| 586 <p>Note that there are three columns in this output. The first column contains t
he |
| 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 n
umber of bytes, while |
| 591 <code>N</code> is the bit offset within the <code>B</code>-th byte. Hence, the b
it position (in |
| 592 bits) is:</p> |
| 593 <pre class="prettyprint"> |
| 594 B*8 + N |
| 595 </pre> |
| 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 bi
t offset <code>192</code> |
| 598 (<code>24*8+0</code>). The fourth record is at bit offset <code>212</code> (<co
de>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’. A
ll 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)</cod
e>.</p> |
| 609 <p>Bit address <code>64:0</code> declares the factorial function address <code>&
#64;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 fun
ction |
| 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</co
de>). Bit address |
| 615 <code>128:0</code> defines an equality comparison of the argument <code>%p0</cod
e> with <code>1</code> |
| 616 (constant <code>%c0</code>). Bit address <code>132:6</code> defines a conditiona
l branch. If the |
| 617 result of the previous comparison (<code>%v0</code>) is true, the program will b
ranch 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</co
de>) 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 accross records. <a class="reference internal" href="#link-for-global
-state-section"><em>Global state</em></a> |
| 628 decribes how this implicit information is modeled. In addition, there are |
| 629 various <a class="reference internal" href="#link-for-support-functions-section"
><em>suppport 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 a
ppear in |
| 632 any block, or can appear in all blocks). <a class="reference internal" href="#l
ink-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 |
| 636 boundaries.</p> |
| 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="refere
nce internal" href="#link-for-globals-block-section"><em>globals |
| 641 block</em></a>. <a class="reference internal" href="#link-for-function-address-s
ection"><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 defi
ned |
| 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-sec
tion"><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 bl
ock</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-functio
n-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>const
ants block</em></a>. Each function |
| 654 definition is defined by a <a class="reference internal" href="#link-for-functio
n-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-sectio
n"><em>terminator instruction</em></a> is the |
| 661 last instruction in a <a class="reference internal" href="#link-for-function-blo
cks-section"><em>basic block</em></a>, and |
| 662 is a branch/return instruction.</p> |
| 663 <p>There are <a class="reference internal" href="#link-for-integer-binary-instru
ctions"><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-i
nstruction"><em>alloca |
| 671 instruction</em></a>.</p> |
| 672 <p>One can also convert integer and floating point values using <a class="refere
nce 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>Compa
rison 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-intr
insic-functions-section"><em>intrinsic |
| 678 functions</em></a>, as well as |
| 679 <a class="reference internal" href="#link-for-integer-binary-instructions"><em>i
nteger</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-ins
tructions"><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-an
d-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 |
| 687 instructions.</p> |
| 688 <p>Finally, how to pack records is described in the |
| 689 <a class="reference internal" href="#link-for-abbreviations-section"><em>abbrevi
ations</em></a> section.</p> |
| 690 <h2 id="global-state"><span id="link-for-global-state-section"></span>Global Sta
te</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 trac
k |
| 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 |
| 696 values.</p> |
| 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 Coun
ters</em></a> defines counters maintained in the glboal |
| 701 state.</p> |
| 702 <p>In several blocks, one of the first records in the block defines how many val
ues |
| 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 Func
tions</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 |
| 716 </pre> |
| 717 <p>For each type in the <a class="reference internal" href="#link-for-types-bloc
k-section"><em>types block</em></a>, a |
| 718 corresponding inverse map:</p> |
| 719 <pre class="prettyprint"> |
| 720 TypeID: Type -> ID |
| 721 </pre> |
| 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 mai
ntained |
| 724 during updates to map <code>TypeOf</code> (when given a type <code>ID</code>). H
ence, <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 |
| 734 </pre> |
| 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) |
| 740 </pre> |
| 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 |
| 744 defined:</p> |
| 745 <dl class="docutils"> |
| 746 <dt>NumTypes</dt> |
| 747 <dd>The number of types defined so far (in the <a class="reference internal" hre
f="#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> |
| 755 <dt>NumParams</dt> |
| 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="referenc
e 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"><e
m>constants block</em></a>).</dd> |
| 763 <dt>NumBasicBlocks</dt> |
| 764 <dd>The number of basic blocks defined so far (within a <a class="reference inte
rnal" 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>funct
ion block</em></a>).</dd> |
| 769 </dl> |
| 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 recor
ded |
| 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-coun
t"><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-recor
d"><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-rec
ord"><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-initiali
zer"><em>number of initializers</em></a> for |
| 785 a global variable/constant address in the globals block.</dd> |
| 786 </dl> |
| 787 <p>It is assumed that the corresponding <a class="reference internal" href="#lin
k-to-id-counters"><em>ID counters</em></a> are |
| 788 always smaller than the corresponding size variables (except |
| 789 ExpectedInitializers). That is:</p> |
| 790 <blockquote> |
| 791 <div>NumBasicBlocks < ExpectedBasicBlocks |
| 792 NumTypes < ExpectedTypes |
| 793 NumGlobalAddresses < ExpectedGlobals</div></blockquote> |
| 794 <h3 id="other-variables"><span id="link-to-other-variables"></span>Other Variabl
es</h3> |
| 795 <dl class="docutils"> |
| 796 <dt>EnclosingFcnID</dt> |
| 797 <dd>The function ID of the function block being processed.</dd> |
| 798 </dl> |
| 799 <p>ConstantsSetType</p> |
| 800 <blockquote> |
| 801 <div>Holds the type associated with the last <a class="reference internal" href=
"#link-for-constants-set-type-record"><em>set type |
| 802 record</em></a> in the constants block. Note: at |
| 803 the beginning of each constants block, this variable is set to type void.</div><
/blockquote> |
| 804 <h2 id="global-records"><span id="link-for-global-record-codes"></span>Global Re
cords</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"> |
| 810 <dt>Header</dt> |
| 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 a
s |
| 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
> |
| 815 <dt>Enter</dt> |
| 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> |
| 819 <dt>Exit</dt> |
| 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>ab
breviation 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> |
| 828 </dl> |
| 829 <p>All global records can’t have user-defined abbreviations associated wit
h |
| 830 them. The <a class="reference internal" href="#link-for-default-abbreviations"><
em>default abbreviation</em></a> is always |
| 831 used.</p> |
| 832 <h3 id="header-record"><span id="link-for-header-record-section"></span>Header R
ecord</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> |
| 841 </pre> |
| 842 <p><strong>Semantics</strong>:</p> |
| 843 <p>The header record defines the initial sequence of bytes that must appear at t
he |
| 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 |
| 851 | 0> | |
| 852 </pre> |
| 853 <h3 id="enter-block-record"><span id="link-for-enter-block-record-section"></spa
n>Enter Block Record</h3> |
| 854 <p>Block records can be top-level, as well as nested in other blocks. Blocks mus
t |
| 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>exi
t</em></a> record.</p> |
| 857 <p><strong>Syntax</strong>:</p> |
| 858 <pre class="prettyprint"> |
| 859 N { <B> |
| 860 </pre> |
| 861 <p><strong>Record</strong>:</p> |
| 862 <pre class="prettyprint"> |
| 863 1: <65535, ID, B> |
| 864 </pre> |
| 865 <p><strong>Semantics</strong>:</p> |
| 866 <p>Enter block records define the beginning of a block. <code>B</code>, if pres
ent, 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>. Vali
d names and corresponding |
| 870 <code>BlockID</code> values are defined as follows:</p> |
| 871 <table border="1" class="docutils"> |
| 872 <colgroup> |
| 873 </colgroup> |
| 874 <thead valign="bottom"> |
| 875 <tr class="row-odd"><th class="head">N</th> |
| 876 <th class="head">Block ID</th> |
| 877 </tr> |
| 878 </thead> |
| 879 <tbody valign="top"> |
| 880 <tr class="row-even"><td>abbreviations</td> |
| 881 <td>0</td> |
| 882 </tr> |
| 883 <tr class="row-odd"><td>constants</td> |
| 884 <td>11</td> |
| 885 </tr> |
| 886 <tr class="row-even"><td>function</td> |
| 887 <td>12</td> |
| 888 </tr> |
| 889 <tr class="row-odd"><td>globals</td> |
| 890 <td>19</td> |
| 891 </tr> |
| 892 <tr class="row-even"><td>module</td> |
| 893 <td>8</td> |
| 894 </tr> |
| 895 <tr class="row-odd"><td>types</td> |
| 896 <td>17</td> |
| 897 </tr> |
| 898 <tr class="row-even"><td>valuesymtab</td> |
| 899 <td>14</td> |
| 900 </tr> |
| 901 </tbody> |
| 902 </table> |
| 903 <p>Note: For readability, PNaClAsm defines a more readable form of a function bl
ock |
| 904 enter record. See <a class="reference internal" href="#link-for-function-blocks
-section"><em>function blocks</em></a> for |
| 905 more details.</p> |
| 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> |} |
| 922 </pre> |
| 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 an |
| 926 <em>exit</em> record.</p> |
| 927 <p><strong>Syntax</strong>:</p> |
| 928 <pre class="prettyprint"> |
| 929 } |
| 930 </pre> |
| 931 <p><strong>Record</strong>:</p> |
| 932 <pre class="prettyprint"> |
| 933 0: <65534> |
| 934 </pre> |
| 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> |} |
| 954 </pre> |
| 955 <h3 id="abbreviation-record"><span id="link-for-abbreviation-record"></span>Abbr
eviation Record</h3> |
| 956 <p>Abbreviation records define abbreviations. See |
| 957 <a class="reference internal" href="#link-for-abbreviations-section"><em>abbrevi
ations</em></a> for details on how abbreviations should be |
| 958 written. This section only presents the mechanical details for converting |
| 959 an abbreviation into a PNaCl record.</p> |
| 960 <p><strong>Syntax</strong>:</p> |
| 961 <pre class="prettyprint"> |
| 962 A = abbrev <E1, ... , EM>; |
| 963 </pre> |
| 964 <p><strong>Record</strong>:</p> |
| 965 <pre class="prettyprint"> |
| 966 2: <65533, M, EE1, ... , EEM> |
| 967 </pre> |
| 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 int
ernal" 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), m
ust |
| 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 follo
wing table:</p> |
| 977 <table border="1" class="docutils"> |
| 978 <colgroup> |
| 979 </colgroup> |
| 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> |
| 984 </tr> |
| 985 </thead> |
| 986 <tbody valign="top"> |
| 987 <tr class="row-even"><td>C</td> |
| 988 <td>1, C</td> |
| 989 <td>Literal C in corresponding position in record.</td> |
| 990 </tr> |
| 991 <tr class="row-odd"><td>fixed(N)</td> |
| 992 <td>0, 1, N</td> |
| 993 <td>Encode value as a fixed sequence of N bits.</td> |
| 994 </tr> |
| 995 <tr class="row-even"><td>vbr(N)</td> |
| 996 <td>0, 2, N</td> |
| 997 <td>Encode value using a variable bit rate of N.</td> |
| 998 </tr> |
| 999 <tr class="row-odd"><td>char6</td> |
| 1000 <td>0, 4</td> |
| 1001 <td>Encode value as 6-bit char containing characters [a-zA-Z0-9._].</td> |
| 1002 </tr> |
| 1003 <tr class="row-even"><td>array(EM)</td> |
| 1004 <td>0, 3</td> |
| 1005 <td>Allow zero or more of the enclosed encoding.</td> |
| 1006 </tr> |
| 1007 </tbody> |
| 1008 </table> |
| 1009 <p>Notationally, Array(EM) encloses the encoding EM, and must appear at the end
of |
| 1010 the abbreviation. When encoding <code>array(EM), array and EM</code> are the las
t two |
| 1011 entries in an abbreviation, the trailing EM is omitted from the syntax, since it |
| 1012 is redundant.</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 |
| 1017 | 0> | |
| 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)>
;; |
| 1032 | 2> | |
| 1033 61:7| 2: <65533, 2, 1, 4, 0, 2,| @a1 = abbrev <4, vbr(8)>; |
| 1034 | 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)>; |
| 1037 | 8> | |
| 1038 71:2| 1: <1, 12> | function: |
| 1039 73:6| 2: <65533, 4, 1, 20, 0, | @a0 = abbrev <20, vbr(6), vb
r(4), |
| 1040 | 2, 6, 0, 2, 4, 0, 2, | vbr(4)>; |
| 1041 | 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)>
; |
| 1048 | 2, 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), vb
r(6), |
| 1053 | 2, 6, 0, 2, 6, 0, 2, | vbr(4)>; |
| 1054 | 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)>; |
| 1059 | 8> | |
| 1060 116:4| 2: <65533, 2, 1, 2, 0, 2,| @a2 = abbrev <2, vbr(8)>; |
| 1061 | 8> | |
| 1062 119:5| 2: <65533, 3, 1, 3, 0, 3,| @a3 = abbrev <3, array(fixed
(8))> |
| 1063 | 0, 1, 8> | ; |
| 1064 123:2| 2: <65533, 2, 1, 4, 0, 2,| @a4 = abbrev <4, vbr(6)>; |
| 1065 | 6> | |
| 1066 126:3| 2: <65533, 3, 1, 4, 0, 2,| @a5 = abbrev <4, vbr(6), vbr
(6)>; |
| 1067 | 6, 0, 2, 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&
gt; |
| 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 %p
1) { |
| 1085 | | // BlockID = 12 |
| 1086 192:0| 3: <1, 1> | blocks 1; |
| 1087 | | %b0: |
| 1088 194:6| 5: <2, 2, 1, 0> | %v0 = add i32 %p0, %p1; <@a
1> |
| 1089 197:2| 5: <2, 3, 1, 0> | %v1 = add i32 %p0, %v0; <@a
1> |
| 1090 199:6| 8: <10, 1> | ret i32 %v1; <@a4> |
| 1091 201:0| 0: <65534> | } |
| 1092 204:0|0: <65534> |} |
| 1093 </pre> |
| 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-glob
als-block-section"><em>globals |
| 1100 block</em></a>, the <a class="reference internal" href="#link-for-valuesymtab-bl
ock-section"><em>valuesymtab |
| 1101 block</em></a>, and any <a class="reference internal" href="#link-for-function-b
locks-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> |
| 1114 <dt>Void type</dt> |
| 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> |
| 1120 </dl> |
| 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 appe
ar |
| 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" hre
f="#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 |
| 1135 file.</p> |
| 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> | } |
| 1145 </pre> |
| 1146 <p>This example defines a types block that defines four type IDs:</p> |
| 1147 <dl class="docutils"> |
| 1148 <dt>@t0</dt> |
| 1149 <dd>A 32-bit integer type.</dd> |
| 1150 <dt>@t1</dt> |
| 1151 <dd>A 32-bit floating point type.</dd> |
| 1152 <dt>@t2</dt> |
| 1153 <dd>The void type.</dd> |
| 1154 <dt>@t3</dt> |
| 1155 <dd>A function, taking 32-bit integer and float point arguments that returns |
| 1156 void.</dd> |
| 1157 </dl> |
| 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"> |
| 1164 count N; <A> |
| 1165 </pre> |
| 1166 <p><strong>Record</strong>:</p> |
| 1167 <pre class="prettyprint"> |
| 1168 AA: <1, N> |
| 1169 </pre> |
| 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) & |
| 1177 0 == NumTypes |
| 1178 </pre> |
| 1179 <p><strong>Updates</strong>:</p> |
| 1180 <blockquote> |
| 1181 <div>ExpectedTypes = N;</div></blockquote> |
| 1182 <p><strong>Examples</strong>:</p> |
| 1183 <pre class="prettyprint"> |
| 1184 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 1185 48:0| 3: <1, 4> | count 4; |
| 1186 50:4| 3: <7, 32> | @t0 = i32; |
| 1187 53:6| 3: <3> | @t1 = float; |
| 1188 55:4| 3: <2> | @t2 = void; |
| 1189 57:2| 3: <21, 0, 2, 0, 1> | @t3 = void (i32, float); |
| 1190 62:0| 0: <65534> | } |
| 1191 </pre> |
| 1192 <h3 id="void-type">Void Type</h3> |
| 1193 <p>The <em>void</em> type record defines the void type, which corresponds to the
type that |
| 1194 doesn’t define any value, and has no size.</p> |
| 1195 <p><strong>Syntax</strong>:</p> |
| 1196 <pre class="prettyprint"> |
| 1197 @tN = void; <A> |
| 1198 </pre> |
| 1199 <p><strong>Record</strong>:</p> |
| 1200 <pre class="prettyprint"> |
| 1201 AA: <2> |
| 1202 </pre> |
| 1203 <p><strong>Semantics</strong>:</p> |
| 1204 <p>The void type record defines the type that has no values and has no size.</p> |
| 1205 <p><strong>Constraints</strong>:</p> |
| 1206 <pre class="prettyprint"> |
| 1207 AA == AbbrevIndex(A) & |
| 1208 N == NumTypes |
| 1209 </pre> |
| 1210 <p><strong>Updates</strong>:</p> |
| 1211 <pre class="prettyprint"> |
| 1212 ++NumTypes; |
| 1213 TypeOf(@tN) = void; |
| 1214 </pre> |
| 1215 <p><strong>Examples</strong>:</p> |
| 1216 <pre class="prettyprint"> |
| 1217 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 1218 48:0| 3: <1, 4> | count 4; |
| 1219 50:4| 3: <7, 32> | @t0 = i32; |
| 1220 53:6| 3: <3> | @t1 = float; |
| 1221 55:4| 3: <2> | @t2 = void; |
| 1222 62:0| 0: <65534> | } |
| 1223 </pre> |
| 1224 <h3 id="integer-types">Integer Types</h3> |
| 1225 <p>PNaClAsm allows integer types for various bit sizes. Valid bit sizes are 1, 8
, |
| 1226 16, 32, and 64. Integers can be signed or unsigned, but the signed component of |
| 1227 an integer is not specified by the type. Rather, individual instructions |
| 1228 determine whether the value is assumed to be signed or unsigned.</p> |
| 1229 <p>It should be noted that in PNaClAsm, all pointers are implemented as 32-bit |
| 1230 (unsigned) integers. There isn’t a separate type for pointers. The only w
ay to |
| 1231 tell that a 32-bit integer is a pointer, is when it is used in an instruction |
| 1232 that requires a pointer (such as load and store instructions).</p> |
| 1233 <p><strong>Syntax</strong>:</p> |
| 1234 <pre class="prettyprint"> |
| 1235 @tN = iB; <A> |
| 1236 </pre> |
| 1237 <p><strong>Record</strong>:</p> |
| 1238 <pre class="prettyprint"> |
| 1239 AA: <7, B> |
| 1240 </pre> |
| 1241 <p><strong>Semantics</strong>:</p> |
| 1242 <p>An integer type record defines an integer type. <code>B</code> defines the nu
mber of bits |
| 1243 of the integer type.</p> |
| 1244 <p><strong>Constraints</strong>:</p> |
| 1245 <pre class="prettyprint"> |
| 1246 AA == AbbrevIndex(A) & |
| 1247 N == NumTypes & |
| 1248 B in {1, 8, 16, 32, 64} |
| 1249 </pre> |
| 1250 <p><strong>Updates</strong>:</p> |
| 1251 <pre class="prettyprint"> |
| 1252 ++NumTypes; |
| 1253 TypeOf(@tN) = iB; |
| 1254 </pre> |
| 1255 <p><strong>Examples</strong>:</p> |
| 1256 <pre class="prettyprint"> |
| 1257 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 1258 48:0| 3: <1, 7> | count 7; |
| 1259 50:4| 3: <7, 64> | @t0 = i64; |
| 1260 53:6| 3: <7, 1> | @t1 = i1; |
| 1261 56:2| 3: <7, 8> | @t2 = i8; |
| 1262 58:6| 3: <7, 16> | @t3 = i16; |
| 1263 61:2| 3: <7, 32> | @t4 = i32; |
| 1264 64:4| 3: <21, 0, 0, 1> | @t5 = i64 (i1); |
| 1265 68:4| 3: <2> | @t6 = void; |
| 1266 70:2| 0: <65534> | } |
| 1267 </pre> |
| 1268 <h3 id="bit-floating-point-type">32-Bit Floating Point Type</h3> |
| 1269 <p>PNaClAsm allows computation on 32-bit floating point values. A floating point |
| 1270 type record defines the 32-bit floating point type.</p> |
| 1271 <p><strong>Syntax</strong>:</p> |
| 1272 <pre class="prettyprint"> |
| 1273 @tN = float; <A> |
| 1274 </pre> |
| 1275 <p><strong>Record</strong>:</p> |
| 1276 <pre class="prettyprint"> |
| 1277 AA: <3> |
| 1278 </pre> |
| 1279 <p><strong>Semantics</strong>:</p> |
| 1280 <p>A floating point type record defines the 32-bit floating point type.</p> |
| 1281 <p><strong>Constraints</strong>:</p> |
| 1282 <pre class="prettyprint"> |
| 1283 AA == AbbrevIndex(A) & |
| 1284 N == NumTypes |
| 1285 </pre> |
| 1286 <p><strong>Updates</strong>:</p> |
| 1287 <pre class="prettyprint"> |
| 1288 ++NumTypes; |
| 1289 TypeOf(@tN) = float; |
| 1290 </pre> |
| 1291 <p><strong>Examples</strong>:</p> |
| 1292 <pre class="prettyprint"> |
| 1293 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 1294 48:0| 3: <1, 4> | count 4; |
| 1295 50:4| 3: <4> | @t0 = double; |
| 1296 52:2| 3: <3> | @t1 = float; |
| 1297 54:0| 3: <21, 0, 0, 1> | @t2 = double (float); |
| 1298 58:0| 3: <2> | @t3 = void; |
| 1299 59:6| 0: <65534> | } |
| 1300 </pre> |
| 1301 <h3 id="id1">64-bit Floating Point Type</h3> |
| 1302 <p>PNaClAsm allows computation on 64-bit floating point values. A 64-bit floatin
g |
| 1303 type record defines the 64-bit floating point type.</p> |
| 1304 <p><strong>Syntax</strong>:</p> |
| 1305 <pre class="prettyprint"> |
| 1306 @tN = double; <A> |
| 1307 </pre> |
| 1308 <p><strong>Record</strong>:</p> |
| 1309 <pre class="prettyprint"> |
| 1310 AA: <4> |
| 1311 </pre> |
| 1312 <p><strong>Semantics</strong>:</p> |
| 1313 <p>A double type record defines the 64-bit floating point type.</p> |
| 1314 <p><strong>Constraints</strong>:</p> |
| 1315 <pre class="prettyprint"> |
| 1316 AA == AbbrevIndex(A) & |
| 1317 N == NumTypes |
| 1318 </pre> |
| 1319 <p><strong>Updates</strong>:</p> |
| 1320 <pre class="prettyprint"> |
| 1321 ++NumTypes; |
| 1322 TypeOf(@tN) = double; |
| 1323 </pre> |
| 1324 <p><strong>Examples</strong>:</p> |
| 1325 <pre class="prettyprint"> |
| 1326 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 1327 48:0| 3: <1, 4> | count 4; |
| 1328 50:4| 3: <4> | @t0 = double; |
| 1329 52:2| 3: <3> | @t1 = float; |
| 1330 54:0| 3: <21, 0, 0, 1> | @t2 = double (float); |
| 1331 58:0| 3: <2> | @t3 = void; |
| 1332 59:6| 0: <65534> | } |
| 1333 </pre> |
| 1334 <h3 id="vector-types">Vector Types</h3> |
| 1335 <p>A vector type is a derived type that represents a vector of elements. Vector |
| 1336 types are used when multiple primitive data values are operated in parallel |
| 1337 using a single (SIMD) <a class="reference internal" href="#link-for-vector-instr
uctions"><em>vector instruction</em></a>. A |
| 1338 vector type requires a size (number of elements) and an underlying primitive |
| 1339 data type.</p> |
| 1340 <p><strong>Syntax</strong>:</p> |
| 1341 <pre class="prettyprint"> |
| 1342 @tN = < E x T > <A> |
| 1343 </pre> |
| 1344 <p><strong>Record</strong>:</p> |
| 1345 <pre class="prettyprint"> |
| 1346 AA: <12, E, TT> |
| 1347 </pre> |
| 1348 <p><strong>Semantics</strong>:</p> |
| 1349 <p>The vector type defines a vector of elements. <code>T</code> is the type of e
ach |
| 1350 element. <code>E</code> is the number of elements in the vector.</p> |
| 1351 <p>Vector types can only be defined on <code>i1</code>, <code>i8</code>, <code>i
16</code>, <code>i32</code>, and |
| 1352 <code>float</code>. All vector types, except those on <code>i1</code>, must con
tain exactly 128 |
| 1353 bits. The valid element sizes are restricted as follows:</p> |
| 1354 <table border="1" class="docutils"> |
| 1355 <colgroup> |
| 1356 </colgroup> |
| 1357 <thead valign="bottom"> |
| 1358 <tr class="row-odd"><th class="head">Type</th> |
| 1359 <th class="head">Valid element sizes</th> |
| 1360 </tr> |
| 1361 </thead> |
| 1362 <tbody valign="top"> |
| 1363 <tr class="row-even"><td>i1</td> |
| 1364 <td>4, 8, 16</td> |
| 1365 </tr> |
| 1366 <tr class="row-odd"><td>i8</td> |
| 1367 <td>16</td> |
| 1368 </tr> |
| 1369 <tr class="row-even"><td>i16</td> |
| 1370 <td>8</td> |
| 1371 </tr> |
| 1372 <tr class="row-odd"><td>i32</td> |
| 1373 <td>4</td> |
| 1374 </tr> |
| 1375 <tr class="row-even"><td>float</td> |
| 1376 <td>4</td> |
| 1377 </tr> |
| 1378 </tbody> |
| 1379 </table> |
| 1380 <p><strong>Constraints</strong>:</p> |
| 1381 <pre class="prettyprint"> |
| 1382 AA == AbbrevIndex(A) & |
| 1383 TT == AbsoluteIndex(TypeID(T)) & |
| 1384 N == NumTypes |
| 1385 </pre> |
| 1386 <p><strong>Updates</strong>:</p> |
| 1387 <pre class="prettyprint"> |
| 1388 ++NumTypes |
| 1389 TypeOf(@tN) = <E x T> |
| 1390 </pre> |
| 1391 <p><strong>Examples</strong>:</p> |
| 1392 <pre class="prettyprint"> |
| 1393 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 1394 48:0| 3: <1, 14> | count 14; |
| 1395 50:4| 3: <7, 32> | @t0 = i32; |
| 1396 53:6| 3: <7, 1> | @t1 = i1; |
| 1397 56:2| 3: <2> | @t2 = void; |
| 1398 58:0| 3: <12, 4, 1> | @t3 = <4 x i1>; |
| 1399 61:2| 3: <12, 8, 1> | @t4 = <8 x i1>; |
| 1400 64:4| 3: <12, 16, 1> | @t5 = <16 x i1>; |
| 1401 67:6| 3: <7, 8> | @t6 = i8; |
| 1402 70:2| 3: <12, 16, 6> | @t7 = <16 x i8>; |
| 1403 73:4| 3: <7, 16> | @t8 = i16; |
| 1404 76:0| 3: <12, 8, 8> | @t9 = <8 x i16>; |
| 1405 79:2| 3: <12, 4, 0> | @t10 = <4 x i32>; |
| 1406 82:4| 3: <3> | @t11 = float; |
| 1407 84:2| 3: <12, 4, 11> | @t12 = <4 x float>; |
| 1408 87:4| 3: <21, 0, 2> | @t13 = void (); |
| 1409 90:6| 0: <65534> | } |
| 1410 </pre> |
| 1411 <h3 id="function-type"><span id="link-for-function-type"></span>Function Type</h
3> |
| 1412 <p>The <em>function</em> type can be thought of as a function signature. It cons
ists of a |
| 1413 return type, and a (possibly empty) list of formal parameter types.</p> |
| 1414 <p><strong>Syntax</strong>:</p> |
| 1415 <pre class="prettyprint"> |
| 1416 %tN = RT (T1, ... , TM) <A> |
| 1417 </pre> |
| 1418 <p><strong>Record</strong>:</p> |
| 1419 <pre class="prettyprint"> |
| 1420 AA: <21, 0, IRT, IT1, ... , ITM> |
| 1421 </pre> |
| 1422 <p><strong>Semantics</strong>:</p> |
| 1423 <p>The function type defines the signature of a function. <code>RT</code> is the
return type |
| 1424 of the function, while types <code>T1</code> through <code>TM</code> are the typ
es of the |
| 1425 arguments. Indices to the corresponding type identifiers are stored in the |
| 1426 corresponding record.</p> |
| 1427 <p>The return value must either be a primitive type, type <code>void</code>, or
a vector |
| 1428 type. Parameter types can be a primitive or vector type.</p> |
| 1429 <p>For ordinary functions, the only valid integer types that can be used for a |
| 1430 return or parameter type are <code>i32</code> and <code>i64</code>. All other i
nteger types are |
| 1431 not allowed.</p> |
| 1432 <p>For <a class="reference internal" href="#link-for-intrinsic-functions-section
"><em>intrinsic functions</em></a>, all |
| 1433 integer types are allowed for both return and parameter types.</p> |
| 1434 <p><strong>Constraints</strong>:</p> |
| 1435 <pre class="prettyprint"> |
| 1436 AA == AbbrevIndex(A) & |
| 1437 M >= 0 & |
| 1438 IRT == AbsoluteIndex(TypeID(RT)) & |
| 1439 IT1 == AbsoluteIndex(TypeID(T1)) & |
| 1440 ... |
| 1441 ITM == AbsoluteIndex(TypeID(TM)) & |
| 1442 N == NumTypes |
| 1443 </pre> |
| 1444 <p><strong>Updates</strong>:</p> |
| 1445 <pre class="prettyprint"> |
| 1446 ++NumTypes |
| 1447 TypeOf(@tN) = RT (T1, ... , TM) |
| 1448 </pre> |
| 1449 <p><strong>Examples</strong>:</p> |
| 1450 <pre class="prettyprint"> |
| 1451 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 1452 48:0| 3: <1, 7> | count 7; |
| 1453 50:4| 3: <7, 32> | @t0 = i32; |
| 1454 53:6| 3: <3> | @t1 = float; |
| 1455 55:4| 3: <4> | @t2 = double; |
| 1456 57:2| 3: <21, 0, 2, 1> | @t3 = double (float); |
| 1457 61:2| 3: <2> | @t4 = void; |
| 1458 63:0| 3: <21, 0, 4> | @t5 = void (); |
| 1459 66:2| 3: <21, 0, 0, 0, 1, 0, 2>| @t6 = |
| 1460 | | i32 (i32, float, i32, double); |
| 1461 72:4| 0: <65534> | } |
| 1462 </pre> |
| 1463 <h2 id="globals-block"><span id="link-for-globals-block-section"></span>Globals
Block</h2> |
| 1464 <p>The globals block defines global addresses of variables and constants, used b
y |
| 1465 the PNaCl program. It also defines the memory associated with the global |
| 1466 addresses, and how to initialize each global variable/constant. It must appear |
| 1467 in the <a class="reference internal" href="#link-for-module-block"><em>module bl
ock</em></a>. It must appear after the |
| 1468 <a class="reference internal" href="#link-for-types-block-section"><em>types blo
ck</em></a>, as well as after all |
| 1469 <a class="reference internal" href="#link-for-function-address-section"><em>func
tion address</em></a> records. But, it must |
| 1470 also appear before the <a class="reference internal" href="#link-for-valuesymtab
-block-section"><em>valuesymtab |
| 1471 block</em></a>, and any |
| 1472 <a class="reference internal" href="#link-for-function-blocks-section"><em>funct
ion blocks</em></a>.</p> |
| 1473 <p>The globals block begins with a <a class="reference internal" href="#link-for
-globals-count-record"><em>count |
| 1474 record</em></a>, defining how many global addresses are |
| 1475 defined by the PNaCl program. It is then followed by a sequence of records that |
| 1476 defines each global address, and how each global address is initialized.</p> |
| 1477 <p>The standard sequence, for defining global addresses, begins with a global |
| 1478 address record. It is then followed by a sequence of records defining how the |
| 1479 global address is initialized. If the initializer is simple, a single record is |
| 1480 used. Otherwise, the initializer is preceded with a <a class="reference internal
" href="#link-for-compound-initializer"><em>compound |
| 1481 record</em></a>, specifying a number <em>N</em>, followed by |
| 1482 sequence of <em>N</em> simple initializer records.</p> |
| 1483 <p>The size of the memory referenced by each global address is defined by its |
| 1484 initializer records. All simple initializer records define a sequence of |
| 1485 bytes. A compound initializer defines the sequence of bytes by concatenating the |
| 1486 corresponding sequence of bytes for each of its simple initializer records.</p> |
| 1487 <p>For notational convenience, PNaClAsm begins a compound record with a “{
”, and |
| 1488 inserts a “}” after the last initializer record associated with the
compound |
| 1489 record. This latter “}” does not correspond to any record. It is imp
licitly |
| 1490 assumed by the size specified in the compound record, and is added only to |
| 1491 improve readability.</p> |
| 1492 <p>Explicit alignment is specified for global addresses, and must be a power of |
| 1493 2. See <a class="reference internal" href="#link-for-memory-blocks-and-alignment
-section"><em>memory blocks and |
| 1494 alignment</em></a> for a more detailed |
| 1495 discussion on how to define alignment.</p> |
| 1496 <p>For example, consider the following pnacl-bcdis output snippet:</p> |
| 1497 <pre class="prettyprint"> |
| 1498 52:0| 1: <65535, 19, 2> | globals { // BlockID = 19 |
| 1499 60:0| 3: <5, 2> | count 2; |
| 1500 62:4| 3: <0, 1, 1> | const @g0, align 1, |
| 1501 65:6| 3: <2, 8> | zerofill 8; |
| 1502 68:2| 3: <0, 1, 0> | var @g1, align 1, |
| 1503 71:4| 3: <1, 2> | initializers 2 { |
| 1504 74:0| 3: <3, 1, 2, 3, 4> | { 1, 2, 3, 4} |
| 1505 78:6| 3: <2, 2> | zerofill 2; |
| 1506 | | } |
| 1507 81:2| 0: <65534> | } |
| 1508 </pre> |
| 1509 <p>This snippet defines the global constant <code>@g0</code>, and the global
variable |
| 1510 <code>@g1</code>. <code>@g0</code> is 8 bytes long, and initialized to z
ero. <code>@g1</code> is |
| 1511 initialized with 6 bytes: <code>1 2 3 4 0 0</code>.</p> |
| 1512 <h3 id="link-for-globals-count-record"><span id="id2"></span>Count Record</h3> |
| 1513 <p>The count record defines the number of global addresses used by the PNaCl |
| 1514 program.</p> |
| 1515 <p><strong>Syntax</strong>:</p> |
| 1516 <pre class="prettyprint"> |
| 1517 count N; <A> |
| 1518 </pre> |
| 1519 <p><strong>Record</strong>:</p> |
| 1520 <pre class="prettyprint"> |
| 1521 AA: <5, N> |
| 1522 </pre> |
| 1523 <p><strong>Semantics</strong>:</p> |
| 1524 <p>This record must appear first in the globals block. The count record defines |
| 1525 the number of global addresses used by the program.</p> |
| 1526 <p><strong>Constraints</strong>:</p> |
| 1527 <pre class="prettyprint"> |
| 1528 AA == AbbrevIndex(A) |
| 1529 </pre> |
| 1530 <p><strong>Updates</strong>:</p> |
| 1531 <pre class="prettyprint"> |
| 1532 ExpectedGlobals = N; |
| 1533 ExpectedInitializers = 0; |
| 1534 </pre> |
| 1535 <p><strong>Examples</strong>:</p> |
| 1536 <pre class="prettyprint"> |
| 1537 52:0| 1: <65535, 19, 2> | globals { // BlockID = 19 |
| 1538 60:0| 3: <5, 2> | count 2; |
| 1539 62:4| 3: <0, 1, 1> | const @g0, align 1, |
| 1540 65:6| 3: <2, 8> | zerofill 8; |
| 1541 68:2| 3: <0, 1, 0> | var @g1, align 1, |
| 1542 71:4| 3: <1, 2> | initializers 2 { |
| 1543 74:0| 3: <3, 1, 2, 3, 4> | { 1, 2, 3, 4} |
| 1544 78:6| 3: <2, 2> | zerofill 2; |
| 1545 | | } |
| 1546 81:2| 0: <65534> | } |
| 1547 </pre> |
| 1548 <h3 id="global-variable-addresses"><span id="link-for-global-variable-address"><
/span>Global Variable Addresses</h3> |
| 1549 <p>A global variable address record defines a global address to global data. Th
e |
| 1550 global variable address record must be immediately followed by initializer |
| 1551 record(s) that define how the corresponding global variable is initialized.</p> |
| 1552 <p><strong>Syntax</strong>:</p> |
| 1553 <pre class="prettyprint"> |
| 1554 var @gN, align V, <A> |
| 1555 </pre> |
| 1556 <p><strong>Record</strong>:</p> |
| 1557 <pre class="prettyprint"> |
| 1558 AA: <0, VV, 0> |
| 1559 </pre> |
| 1560 <p><strong>Semantics</strong>:</p> |
| 1561 <p>A global variable address record defines a global address for a global variab
le. |
| 1562 <code>V</code> is the <a class="reference internal" href="#link-for-memory-block
s-and-alignment-section"><em>memory |
| 1563 alignment</em></a> for the global variable |
| 1564 address, and is a power of 2.</p> |
| 1565 <p>It is assumed that the memory, referenced by the global variable address, can
be |
| 1566 both read and written to.</p> |
| 1567 <p><strong>Constraints</strong>:</p> |
| 1568 <pre class="prettyprint"> |
| 1569 AA == AbbrevIndex(A) & |
| 1570 N == NumGlobalAddresses & |
| 1571 ExpectedInitializers == 0 & |
| 1572 VV == Log2(V+1) |
| 1573 </pre> |
| 1574 <p><strong>Updates</strong>:</p> |
| 1575 <pre class="prettyprint"> |
| 1576 ++NumGlobalAddresses; |
| 1577 ExpectedInitializers = 1; |
| 1578 TypeOf(@gN) = i32; |
| 1579 </pre> |
| 1580 <p><strong>Examples</strong>:</p> |
| 1581 <pre class="prettyprint"> |
| 1582 52:0| 1: <65535, 19, 2> | globals { // BlockID = 19 |
| 1583 60:0| 3: <5, 2> | count 2; |
| 1584 62:4| 3: <0, 3, 0> | var @g0, align 4, |
| 1585 65:6| 3: <2, 8> | zerofill 8; |
| 1586 68:2| 3: <0, 1, 0> | var @g1, align 1, |
| 1587 71:4| 3: <3, 1, 2, 3, 4> | { 1, 2, 3, 4} |
| 1588 76:2| 0: <65534> | } |
| 1589 80:0|0: <65534> |} |
| 1590 </pre> |
| 1591 <h3 id="global-constant-addresses"><span id="link-for-global-constant-address"><
/span>Global Constant Addresses</h3> |
| 1592 <p>A global constant address record defines an address corresponding to a global |
| 1593 constant that can’t be modified by the program. The global constant addres
s |
| 1594 record must be immediately followed by initializer record(s) that define how |
| 1595 the corresponding global constant is initialized.</p> |
| 1596 <p><strong>Syntax</strong>:</p> |
| 1597 <pre class="prettyprint"> |
| 1598 const @gN, align V, <A> |
| 1599 </pre> |
| 1600 <p><strong>Record</strong>:</p> |
| 1601 <pre class="prettyprint"> |
| 1602 AA: <0, VV, 1> |
| 1603 </pre> |
| 1604 <p><strong>Semantics</strong>:</p> |
| 1605 <p>A global constant address record defines a global address for a global consta
nt. |
| 1606 <code>V</code> is the <a class="reference internal" href="#link-for-memory-block
s-and-alignment-section"><em>memory |
| 1607 alignment</em></a> for the global constant |
| 1608 address, and is a power of 2.</p> |
| 1609 <p>It is assumed that the memory, referenced by the global constant address, is |
| 1610 only read, and can’t be written to.</p> |
| 1611 <p>Note that the only difference between a global variable address and a global |
| 1612 constant address record is the third element of the record. If the value is |
| 1613 zero, it defines a global variable address. If the value is one, it defines a |
| 1614 global constant address.</p> |
| 1615 <p><strong>Constraints</strong>:</p> |
| 1616 <pre class="prettyprint"> |
| 1617 AA == AbbrevIndex(A) & |
| 1618 N == NumGlobalAddresses & |
| 1619 ExpectedInitializers == 0 & |
| 1620 VV == Log2(V+1) |
| 1621 </pre> |
| 1622 <p><strong>Updates</strong>:</p> |
| 1623 <pre class="prettyprint"> |
| 1624 ++NumGlobalAddresses; |
| 1625 ExpectedInitializers = 1; |
| 1626 TypeOf(@gN) = i32; |
| 1627 </pre> |
| 1628 <p><strong>Examples</strong>:</p> |
| 1629 <pre class="prettyprint"> |
| 1630 52:0| 1: <65535, 19, 2> | globals { // BlockID = 19 |
| 1631 60:0| 3: <5, 2> | count 2; |
| 1632 62:4| 3: <0, 3, 1> | const @g0, align 4, |
| 1633 65:6| 3: <2, 8> | zerofill 8; |
| 1634 68:2| 3: <0, 1, 1> | const @g1, align 1, |
| 1635 71:4| 3: <3, 1, 2, 3, 4> | { 1, 2, 3, 4} |
| 1636 76:2| 0: <65534> | } |
| 1637 </pre> |
| 1638 <h3 id="zerofill-initializer">Zerofill Initializer</h3> |
| 1639 <p>The zerofill initializer record initializes a sequence of bytes, associated w
ith |
| 1640 a global address, with zeros.</p> |
| 1641 <p><strong>Syntax</strong>:</p> |
| 1642 <pre class="prettyprint"> |
| 1643 zerofill N; <A> |
| 1644 </pre> |
| 1645 <p><strong>Record</strong>:</p> |
| 1646 <pre class="prettyprint"> |
| 1647 AA: <2, N> |
| 1648 </pre> |
| 1649 <p><strong>Semantics</strong>:</p> |
| 1650 <p>A zerofill initializer record initializes a sequence of bytes, associated wit
h a |
| 1651 global address, with zeros. The number of bytes initialized to zero is <code>N</
code>.</p> |
| 1652 <p><strong>Constraints</strong>:</p> |
| 1653 <pre class="prettyprint"> |
| 1654 AA == AbbrevIndex(A) & |
| 1655 ExpectedInitializers > 0 |
| 1656 </pre> |
| 1657 <p><strong>Updates</strong>:</p> |
| 1658 <pre class="prettyprint"> |
| 1659 --ExpectedInitializers; |
| 1660 </pre> |
| 1661 <p><strong>Examples</strong>:</p> |
| 1662 <pre class="prettyprint"> |
| 1663 52:0| 1: <65535, 19, 2> | globals { // BlockID = 19 |
| 1664 60:0| 3: <5, 2> | count 2; |
| 1665 62:4| 3: <0, 3, 1> | const @g0, align 4, |
| 1666 65:6| 3: <2, 8> | zerofill 8; |
| 1667 68:2| 3: <0, 1, 0> | var @g1, align 1, |
| 1668 71:4| 3: <2, 4> | zerofill 4; |
| 1669 74:0| 0: <65534> | } |
| 1670 </pre> |
| 1671 <h3 id="data-initializer">Data Initializer</h3> |
| 1672 <p>Data records define a sequence of bytes. These bytes define the initial value
of |
| 1673 the contents of the corresponding memory.</p> |
| 1674 <p><strong>Syntax</strong>:</p> |
| 1675 <pre class="prettyprint"> |
| 1676 { B1 , .... , BN } <A> |
| 1677 </pre> |
| 1678 <p><strong>Record</strong>:</p> |
| 1679 <pre class="prettyprint"> |
| 1680 AA: <3, B1, ..., BN> |
| 1681 </pre> |
| 1682 <p><strong>Semantics</strong>:</p> |
| 1683 <p>A data record defines a sequence of (unsigned) bytes <code>B1</code> through
<code>BN</code>, that |
| 1684 initialize <code>N</code> bytes of memory.</p> |
| 1685 <p><strong>Constraints</strong>:</p> |
| 1686 <pre class="prettyprint"> |
| 1687 AA == AbbrevIndex(A) & |
| 1688 ExpectedInitializers > 0 |
| 1689 </pre> |
| 1690 <p><strong>Updates</strong>:</p> |
| 1691 <pre class="prettyprint"> |
| 1692 --ExpectedInitializers; |
| 1693 </pre> |
| 1694 <p><strong>Examples</strong>:</p> |
| 1695 <pre class="prettyprint"> |
| 1696 56:0| 3: <8, 1, 0, 1, 0> | declare external void @f0(); |
| 1697 60:6| 1: <65535, 19, 2> | globals { // BlockID = 19 |
| 1698 68:0| 3: <5, 2> | count 2; |
| 1699 70:4| 3: <0, 1, 1> | const @g0, align 1, |
| 1700 73:6| 3: <3, 1, 2, 97, 36, 44, | { 1, 2, 97, 36, 44, 88, |
| 1701 | 88, 44, 50> | 44, 50} |
| 1702 86:0| 3: <0, 1, 1> | const @g1, align 1, |
| 1703 89:2| 3: <1, 3> | initializers 3 { |
| 1704 91:6| 3: <3, 1, 2, 3, 4> | { 1, 2, 3, 4} |
| 1705 96:4| 3: <4, 0> | reloc @f0; |
| 1706 99:0| 3: <3, 99, 66, 22, 12> | { 99, 66, 22, 12} |
| 1707 | | } |
| 1708 105:2| 0: <65534> | } |
| 1709 </pre> |
| 1710 <h3 id="relocation-initializer">Relocation Initializer</h3> |
| 1711 <p>A relocation initializer record allows one to define the initial value of a |
| 1712 global address with the value of another global address (i.e. either |
| 1713 <a class="reference internal" href="#link-for-function-address-section"><em>func
tion</em></a>, |
| 1714 <a class="reference internal" href="#link-for-global-variable-address"><em>varia
ble</em></a>, or |
| 1715 <a class="reference internal" href="#link-for-global-constant-address"><em>const
ant</em></a>). Since addresses are |
| 1716 pointers, a relocation initializer record defines 4 bytes of memory.</p> |
| 1717 <p><strong>Syntax</strong>:</p> |
| 1718 <pre class="prettyprint"> |
| 1719 reloc V; <A> |
| 1720 </pre> |
| 1721 <p><strong>Record</strong>:</p> |
| 1722 <pre class="prettyprint"> |
| 1723 AA: <4, VV> |
| 1724 </pre> |
| 1725 <p><strong>Semantics</strong>:</p> |
| 1726 <p>A relocation initializer record defines a 4-byte value containing the specifi
ed |
| 1727 global address <code>V</code>.</p> |
| 1728 <p><strong>Constraints</strong>:</p> |
| 1729 <pre class="prettyprint"> |
| 1730 AA == AbbrevIndex(A) & |
| 1731 VV == AbsoluteIndex(V) & |
| 1732 VV >= NumFuncAddresses & |
| 1733 VV < NumFuncAddresses + ExpectedGlobals & |
| 1734 ExpectedInitializers > 0 |
| 1735 </pre> |
| 1736 <p><strong>Updates</strong>:</p> |
| 1737 <blockquote> |
| 1738 <div>–ExpectedInitializers;</div></blockquote> |
| 1739 <p><strong>Examples</strong>:</p> |
| 1740 <pre class="prettyprint"> |
| 1741 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 1742 48:0| 3: <1, 2> | count 2; |
| 1743 50:4| 3: <2> | @t0 = void; |
| 1744 52:2| 3: <21, 0, 0> | @t1 = void (); |
| 1745 55:4| 0: <65534> | } |
| 1746 56:0| 3: <8, 1, 0, 1, 0> | declare external void @f0(); |
| 1747 60:6| 1: <65535, 19, 2> | globals { // BlockID = 19 |
| 1748 68:0| 3: <5, 2> | count 2; |
| 1749 70:4| 3: <0, 1, 0> | var @g0, align 1, |
| 1750 73:6| 3: <1, 3> | initializers 3 { |
| 1751 76:2| 3: <4, 0> | reloc @f0; |
| 1752 78:6| 3: <4, 1> | reloc @g0; |
| 1753 81:2| 3: <4, 2> | reloc @g1; |
| 1754 | | } |
| 1755 83:6| 3: <0, 3, 0> | var @g1, align 4, |
| 1756 87:0| 3: <2, 4> | zerofill 4; |
| 1757 89:4| 0: <65534> | } |
| 1758 </pre> |
| 1759 <p>This example defines global address <code>@g0</code> and <code>@g1</c
ode>. <code>@g0</code> defines 12 |
| 1760 bytes of memory, and is initialized with three addresses <code>@f1</code>, <
code>@g0</code>, and |
| 1761 <code>@g1</code>. Note that all global addresses can be used in a relocation |
| 1762 initialization record, even if it isn’t defined yet.</p> |
| 1763 <h3 id="subfield-relocation-initializer">Subfield Relocation Initializer</h3> |
| 1764 <p>A subfield relocation initializer record allows one to define the initial val
ue |
| 1765 of a global address with the value of another (non-function) global address |
| 1766 (i.e. either <a class="reference internal" href="#link-for-global-variable-addre
ss"><em>variable</em></a> or |
| 1767 <a class="reference internal" href="#link-for-global-constant-address"><em>const
ant</em></a> address), plus a |
| 1768 constant. Since addresses are pointers, a relocation initializer record defines |
| 1769 4 bytes of memory.</p> |
| 1770 <p><strong>Syntax</strong>:</p> |
| 1771 <pre class="prettyprint"> |
| 1772 reloc V + X; <A> |
| 1773 reloc V - X; <A> |
| 1774 </pre> |
| 1775 <p><strong>Record</strong>:</p> |
| 1776 <pre class="prettyprint"> |
| 1777 AA: <4, VV, XXX> |
| 1778 </pre> |
| 1779 <p><strong>Semantics</strong>:</p> |
| 1780 <p>A subfield relocation initializer record defines a 4-byte value containing th
e |
| 1781 specified global (non-function) address <code>V</code>, modified by the unsigned
offset |
| 1782 <code>X</code>. <code>XX</code> is the corresponding signed offset. In the first
form, <code>XX == |
| 1783 X</code>. In the second form, <code>XX == -X</code>.</p> |
| 1784 <p><strong>Constraints</strong>:</p> |
| 1785 <pre class="prettyprint"> |
| 1786 AA == AbbrevIndex(A) |
| 1787 VV == AbsoluteIndex(V) |
| 1788 VV >= NumFuncAddresses |
| 1789 VV < NumFuncAddresses + ExpectedGlobals |
| 1790 ExpectedInitializers > 0 |
| 1791 XXX == SignRotate(XX) |
| 1792 </pre> |
| 1793 <p><strong>Updates</strong>:</p> |
| 1794 <pre class="prettyprint"> |
| 1795 --ExpectedInitializers; |
| 1796 </pre> |
| 1797 <p><strong>Examples</strong>:</p> |
| 1798 <pre class="prettyprint"> |
| 1799 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 1800 48:0| 3: <1, 0> | count 0; |
| 1801 50:4| 0: <65534> | } |
| 1802 52:0| 1: <65535, 19, 2> | globals { // BlockID = 19 |
| 1803 60:0| 3: <5, 3> | count 3; |
| 1804 62:4| 3: <0, 1, 0> | var @g0, align 1, |
| 1805 65:6| 3: <1, 3> | initializers 3 { |
| 1806 68:2| 3: <4, 0, 1> | reloc @g0 + 1; |
| 1807 71:4| 3: <4, 1, 4294967295> | reloc @g1 - 1; |
| 1808 79:2| 3: <4, 2, 4> | reloc @g2 + 4; |
| 1809 | | } |
| 1810 82:4| 3: <0, 3, 0> | var @g1, align 4, |
| 1811 85:6| 3: <2, 4> | zerofill 4; |
| 1812 88:2| 3: <0, 3, 0> | var @g2, align 4, |
| 1813 91:4| 3: <2, 8> | zerofill 8; |
| 1814 94:0| 0: <65534> | } |
| 1815 </pre> |
| 1816 <h3 id="compound-initializer"><span id="link-for-compound-initializer"></span>Co
mpound Initializer</h3> |
| 1817 <p>The compound initializer record must immediately follow a global |
| 1818 <a class="reference internal" href="#link-for-global-variable-address"><em>varia
ble</em></a> or |
| 1819 <a class="reference internal" href="#link-for-global-constant-address"><em>const
ant</em></a> address record. It defines how |
| 1820 many simple initializer records are used to define the initializer. The size of |
| 1821 the corresponding memory is the sum of the bytes needed for each of the |
| 1822 succeeding initializers.</p> |
| 1823 <p>Note that a compound initializer can’t be used as a simple initializer
of |
| 1824 another compound initializer (i.e. nested compound initializers are not |
| 1825 allowed).</p> |
| 1826 <p><strong>Syntax</strong>:</p> |
| 1827 <pre class="prettyprint"> |
| 1828 initializers N { <A> |
| 1829 ... |
| 1830 } |
| 1831 </pre> |
| 1832 <p><strong>Record</strong>:</p> |
| 1833 <pre class="prettyprint"> |
| 1834 AA: <1, N> |
| 1835 </pre> |
| 1836 <p><strong>Semantics</strong>:</p> |
| 1837 <p>Defines that the next <cite>N</cite> initializers should be associated with t
he global |
| 1838 address of the previous record.</p> |
| 1839 <p><strong>Constraints</strong>:</p> |
| 1840 <pre class="prettyprint"> |
| 1841 AA == AbbrevIndex(A) & |
| 1842 ExpectedInitializers == 1 |
| 1843 </pre> |
| 1844 <p><strong>Updates</strong>:</p> |
| 1845 <pre class="prettyprint"> |
| 1846 ExpectedInitializers = N; |
| 1847 </pre> |
| 1848 <p><strong>Examples</strong>:</p> |
| 1849 <pre class="prettyprint"> |
| 1850 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 1851 48:0| 3: <1, 0> | count 0; |
| 1852 50:4| 0: <65534> | } |
| 1853 52:0| 1: <65535, 19, 2> | globals { // BlockID = 19 |
| 1854 60:0| 3: <5, 2> | count 2; |
| 1855 62:4| 3: <0, 0, 1> | const @g0, align 0, |
| 1856 65:6| 3: <1, 2> | initializers 2 { |
| 1857 68:2| 3: <2, 8> | zerofill 8; |
| 1858 70:6| 3: <3, 3, 2, 1, 0> | { 3, 2, 1, 0} |
| 1859 | | } |
| 1860 75:4| 3: <0, 0, 0> | var @g1, align 0, |
| 1861 78:6| 3: <1, 2> | initializers 2 { |
| 1862 81:2| 3: <3, 1, 2, 3, 4> | { 1, 2, 3, 4} |
| 1863 86:0| 3: <2, 2> | zerofill 2; |
| 1864 | | } |
| 1865 88:4| 0: <65534> | } |
| 1866 </pre> |
| 1867 <h2 id="valuesymtab-block"><span id="link-for-valuesymtab-block-section"></span>
Valuesymtab Block</h2> |
| 1868 <p>The valuesymtab block does not define any values. Its only goal is to associ
ate |
| 1869 text names with external <a class="reference internal" href="#link-for-function-
address-section"><em>function |
| 1870 addresses</em></a>. Each association is defined by a |
| 1871 record in the valuesymtab block. Currently, only |
| 1872 <a class="reference internal" href="#link-for-intrinsic-functions-section"><em>i
ntrinsic</em></a> function addresses and |
| 1873 the (external) start function (<code>_start</code>) can be named. All named fun
ction |
| 1874 addresses must be external. Each record in the valuesymtab block is a <em>entry
</em> |
| 1875 record, defining a single name association.</p> |
| 1876 <h3 id="entry-record">Entry Record</h3> |
| 1877 <p>The <em>entry</em> record defines a name for a function address.</p> |
| 1878 <p><strong>Syntax</strong>:</p> |
| 1879 <pre class="prettyprint"> |
| 1880 V : "NAME"; <A> |
| 1881 </pre> |
| 1882 <p><strong>Record</strong>:</p> |
| 1883 <pre class="prettyprint"> |
| 1884 AA: <1, B1, ... , BN> |
| 1885 </pre> |
| 1886 <p><strong>Semantics</strong>:</p> |
| 1887 <p>The <em>entry</em> record defines a name <code>NAME</code> for function addre
ss <code>V</code>. <code>NAME</code> is a |
| 1888 sequence of ANSCII characters <code>B1</code> through <code>BN</code>.</p> |
| 1889 <p><strong>Examples</strong>:</p> |
| 1890 <pre class="prettyprint"> |
| 1891 72:0| 3: <8, 4, 0, 1, 0> | declare external |
| 1892 | | void @f0(i32, i32, i32, i32, i1); |
| 1893 76:6| 3: <8, 4, 0, 1, 0> | declare external |
| 1894 | | void @f1(i32, i32, i32, i32, i1); |
| 1895 81:4| 3: <8, 5, 0, 0, 0> | define external void @f2(i32); |
| 1896 86:2| 1: <65535, 19, 2> | globals { // BlockID = 19 |
| 1897 92:0| 3: <5, 0> | count 0; |
| 1898 94:4| 0: <65534> | } |
| 1899 96:0| 1: <65535, 14, 2> | valuesymtab { // BlockID = 14 |
| 1900 104:0| 3: <1, 1, 108, 108, 118, | @f1 : "llvm.memmove.p0i8.p0i
8.i32"; |
| 1901 | 109, 46, 109, 101, | |
| 1902 | 109, 109, 111, 118, | |
| 1903 | 101, 46, 112, 48, | |
| 1904 | 105, 56, 46, 112, 48,| |
| 1905 | 105, 56, 46, 105, 51,| |
| 1906 | 50> | |
| 1907 145:4| 3: <1, 2, 95, 115, 116, | @f2 : "_start"; |
| 1908 | 97, 114, 116> | |
| 1909 157:0| 3: <1, 0, 108, 108, 118, | @f0 : "llvm.memcpy.p0i8.p0i8
.i32"; |
| 1910 | 109, 46, 109, 101, | |
| 1911 | 109, 99, 112, 121, | |
| 1912 | 46, 112, 48, 105, 56,| |
| 1913 | 46, 112, 48, 105, 56,| |
| 1914 | 46, 105, 51, 50> | |
| 1915 197:0| 0: <65534> | } |
| 1916 </pre> |
| 1917 <h2 id="module-block"><span id="link-for-module-block"></span>Module Block</h2> |
| 1918 <p>The module block, like all blocks, is enclosed in a pair of |
| 1919 <a class="reference internal" href="#link-for-enter-block-record-section"><em>en
ter</em></a> / |
| 1920 <a class="reference internal" href="#link-for-exit-block-record-section"><em>exi
t</em></a> records, using block ID 8. A |
| 1921 well-formed module block consists of the following records (in order):</p> |
| 1922 <dl class="docutils"> |
| 1923 <dt>A version record</dt> |
| 1924 <dd>The <a class="reference internal" href="#link-for-version-record"><em>versio
n record</em></a> communicates which version |
| 1925 of the PNaCl bitcode reader/writer should be used. Note that this is |
| 1926 different than the PNaCl bitcode (ABI) version. The PNaCl bitcode (ABI) |
| 1927 version defines what is expected in records, and is defined in the header |
| 1928 record of the bitcode file. The version record defines the version of the |
| 1929 PNaCl bitcode reader/writer to use to convert records into bit sequences.</dd> |
| 1930 <dt>Optional local abbreviations</dt> |
| 1931 <dd>Defines a list of local <a class="reference internal" href="#link-for-abbrev
iations-section"><em>abbreviations</em></a> |
| 1932 to use for records within the module block.</dd> |
| 1933 <dt>An abbreviations block</dt> |
| 1934 <dd>The <a class="reference internal" href="#link-for-abbreviations-block-sectio
n"><em>abbreviations block</em></a> defines |
| 1935 user-defined, global abbreviations that are used to convert PNaCl records to |
| 1936 bit sequences in blocks following the abbreviations block.</dd> |
| 1937 <dt>A types block</dt> |
| 1938 <dd>The <a class="reference internal" href="#link-for-types-block-section"><em>t
ypes block</em></a> defines the set of all |
| 1939 types used in the program.</dd> |
| 1940 <dt>A non-empty sequence of function address records</dt> |
| 1941 <dd>Each record defines a <a class="reference internal" href="#link-for-function
-address-section"><em>function |
| 1942 address</em></a> used by the program. Function |
| 1943 addresses must either be external, or defined internally by the program. If |
| 1944 they are defined by the program, there must be a <a class="reference internal" h
ref="#link-for-function-blocks-section"><em>function |
| 1945 block</em></a> (appearing later in the module) that |
| 1946 defines the sequence of instructions for each defined function.</dd> |
| 1947 <dt>A globals block defining the global variables.</dt> |
| 1948 <dd>This <a class="reference internal" href="#link-for-globals-block-section"><e
m>block</em></a> defines the set of |
| 1949 global <a class="reference internal" href="#link-for-global-variable-address"><e
m>variable</em></a> and |
| 1950 <a class="reference internal" href="#link-for-global-constant-address"><em>const
ant</em></a> addresses used by the |
| 1951 program. In addition to the addresses, each global variable also defines how |
| 1952 the corresponding global variable is initialized.</dd> |
| 1953 <dt>An optional value symbol table block.</dt> |
| 1954 <dd>This <a class="reference internal" href="#link-for-valuesymtab-block-section
"><em>block</em></a>, if defined, provides |
| 1955 textual names for <a class="reference internal" href="#link-for-function-address
-section"><em>function |
| 1956 addresses</em></a> (previously defined in the |
| 1957 module). Note that only names for intrinsic functions and the start function |
| 1958 are specified.</dd> |
| 1959 <dt>A sequence of function blocks.</dt> |
| 1960 <dd>Each <a class="reference internal" href="#link-for-function-blocks-section">
<em>function block</em></a> defines the |
| 1961 corresponding intermediate representation for each defined function. The |
| 1962 order of function blocks is used to associate them with <a class="reference inte
rnal" href="#link-for-function-address-section"><em>function |
| 1963 addresses</em></a>. The order of the defined |
| 1964 function blocks must follow the same order as the corresponding function |
| 1965 addresses defined in the module block.</dd> |
| 1966 </dl> |
| 1967 <p>Descriptions of the <a class="reference internal" href="#link-for-abbreviatio
ns-section"><em>abbreviations</em></a>, |
| 1968 <a class="reference internal" href="#link-for-types-block-section"><em>types</em
></a>, |
| 1969 <a class="reference internal" href="#link-for-globals-block-section"><em>globals
</em></a>, <a class="reference internal" href="#link-for-valuesymtab-block-secti
on"><em>value symbol |
| 1970 table</em></a>, and |
| 1971 <a class="reference internal" href="#link-for-function-blocks-section"><em>funct
ion</em></a> blocks are not provided |
| 1972 here. See the appropriate reference for more details. The following subsections |
| 1973 describe each of the records that can appear in a module block.</p> |
| 1974 <h3 id="version-record"><span id="link-for-version-record"></span>Version Record
</h3> |
| 1975 <p>The version record defines the implementation of the PNaCl bitstream |
| 1976 reader/writer to use. That is, the implementation that converts PNaCl records to |
| 1977 bit sequences, and converts them back to PNaCl records. Note that this is |
| 1978 different than the PNaCl version of the bitcode file (encoded in the header |
| 1979 record of the bitcode file). The PNaCl version defines the valid forms of PNaCl |
| 1980 records. The version record is specific to the PNaCl version, and may have |
| 1981 different values for different PNaCl versions.</p> |
| 1982 <p>Note that currently, only PNaCl bitcode version 2, and version record value 1
is |
| 1983 defined.</p> |
| 1984 <p><strong>Syntax</strong>:</p> |
| 1985 <pre class="prettyprint"> |
| 1986 version N; <A> |
| 1987 </pre> |
| 1988 <p><strong>Record</strong>:</p> |
| 1989 <pre class="prettyprint"> |
| 1990 AA: <1, N> |
| 1991 </pre> |
| 1992 <p><strong>Semantics</strong>:</p> |
| 1993 <p>The version record defines which PNaCl reader/writer rules should be |
| 1994 followed. <code>N</code> is the version number. Currently <code>N</code> must be
1. Future |
| 1995 versions of PNaCl may define additional legal values.</p> |
| 1996 <p><strong>Constraints</strong>:</p> |
| 1997 <pre class="prettyprint"> |
| 1998 AA == AbbrevIndex(A) |
| 1999 </pre> |
| 2000 <p><em>Examples</em>:</p> |
| 2001 <pre class="prettyprint"> |
| 2002 16:0|1: <65535, 8, 2> |module { // BlockID = 8 |
| 2003 24:0| 3: <1, 1> | version 1; |
| 2004 26:4| 1: <65535, 0, 2> | abbreviations { // BlockID = 0 |
| 2005 36:0| 0: <65534> | } |
| 2006 </pre> |
| 2007 <h3 id="function-address"><span id="link-for-function-address-section"></span>Fu
nction Address</h3> |
| 2008 <p>A function address record describes a function address. <em>Defined</em> func
tion |
| 2009 addresses define <a class="reference internal" href="#link-for-function-blocks-s
ection"><em>implementations</em></a> while |
| 2010 <em>declared</em> function addresses do not.</p> |
| 2011 <p>Since a PNaCl program is assumed to be a complete (statically linked) |
| 2012 executable, All functions should be <em>defined</em> and <em>internal</em>. The
exception to |
| 2013 this are <a class="reference internal" href="#link-for-intrinsic-functions-secti
on"><em>intrinsic functions</em></a>, which |
| 2014 should only be <em>declared</em> and <em>external</em>, since intrinsic function
s will be |
| 2015 automatically converted to appropriate code by the <a class="reference internal"
href="/native-client/overview.html#link-for-pnacl-translator"><em>PNaCl |
| 2016 translator</em></a>.</p> |
| 2017 <p>The implementation of a <em>defined</em> function address is provided by a |
| 2018 corresponding function block, appearing later in the module block. The |
| 2019 association of a <em>defined</em> function address with the corresponding functi
on |
| 2020 block is based on position. The <em>Nth</em> defined function address record, i
n the |
| 2021 module block, has its implementation in the <em>Nth</em> function block of that
module |
| 2022 block.</p> |
| 2023 <p><strong>Syntax</strong>:</p> |
| 2024 <pre class="prettyprint"> |
| 2025 PN LN T0 @fN ( T1 , ... , TM ); <A> |
| 2026 </pre> |
| 2027 <p><strong>Record</strong>:</p> |
| 2028 <pre class="prettyprint"> |
| 2029 AA: <8, T, C, P, L> |
| 2030 </pre> |
| 2031 <p><strong>Semantics</strong>:</p> |
| 2032 <p>Describes the function address <code>@fN</code>. <code>PN</code> is the n
ame that specifies the |
| 2033 prototype value <code>P</code> associated with the function. A function address
is |
| 2034 <em>defined</em> only if <code>P == 0</code>. Otherwise, it is only <em>declared
</em>. The type of the |
| 2035 function is <a class="reference internal" href="#link-for-function-type"><em>fun
ction type</em></a> <code>@tT</code>. <code>L</code> is the |
| 2036 linkage specification corresponding to name <code>LN</code>. <code>C</code> is t
he calling |
| 2037 convention used by the function.</p> |
| 2038 <p>Note that function signature must be defined by a function type in the types |
| 2039 block. Hence, the return value must either be a primitive type, type <code>void<
/code>, |
| 2040 or a vector type.</p> |
| 2041 <p>For ordinary functions, integer parameter and types can only be <code>i32</co
de> and |
| 2042 <code>i64</code>. All other integer types are not allowed. For intrinsic functi
ons, all |
| 2043 integer types are allowed.</p> |
| 2044 <p>Valid prototype names <code>PN</code>, and corresponding <code>P</code> value
s, are:</p> |
| 2045 <table border="1" class="docutils"> |
| 2046 <colgroup> |
| 2047 </colgroup> |
| 2048 <thead valign="bottom"> |
| 2049 <tr class="row-odd"><th class="head">P</th> |
| 2050 <th class="head">PN</th> |
| 2051 </tr> |
| 2052 </thead> |
| 2053 <tbody valign="top"> |
| 2054 <tr class="row-even"><td>1</td> |
| 2055 <td>declare</td> |
| 2056 </tr> |
| 2057 <tr class="row-odd"><td>0</td> |
| 2058 <td>define</td> |
| 2059 </tr> |
| 2060 </tbody> |
| 2061 </table> |
| 2062 <p>Valid linkage names <code>LN</code>, and corresponding <code>L</code> values,
are:</p> |
| 2063 <table border="1" class="docutils"> |
| 2064 <colgroup> |
| 2065 </colgroup> |
| 2066 <thead valign="bottom"> |
| 2067 <tr class="row-odd"><th class="head">L</th> |
| 2068 <th class="head">LN</th> |
| 2069 </tr> |
| 2070 </thead> |
| 2071 <tbody valign="top"> |
| 2072 <tr class="row-even"><td>3</td> |
| 2073 <td>internal</td> |
| 2074 </tr> |
| 2075 <tr class="row-odd"><td>0</td> |
| 2076 <td>external</td> |
| 2077 </tr> |
| 2078 </tbody> |
| 2079 </table> |
| 2080 <p>Currently, only one calling convention <code>C</code> is supported:</p> |
| 2081 <table border="1" class="docutils"> |
| 2082 <colgroup> |
| 2083 </colgroup> |
| 2084 <thead valign="bottom"> |
| 2085 <tr class="row-odd"><th class="head">C</th> |
| 2086 <th class="head">Calling Convention</th> |
| 2087 </tr> |
| 2088 </thead> |
| 2089 <tbody valign="top"> |
| 2090 <tr class="row-even"><td>0</td> |
| 2091 <td>C calling convention</td> |
| 2092 </tr> |
| 2093 </tbody> |
| 2094 </table> |
| 2095 <p><strong>Constraints</strong>:</p> |
| 2096 <pre class="prettyprint"> |
| 2097 AA = AbbrevIndex(A) & |
| 2098 T = TypeID(TypeOf(T0 ( T1 , ... , TN ))) & |
| 2099 N = NumFuncAddresses |
| 2100 </pre> |
| 2101 <p><strong>Updates</strong>:</p> |
| 2102 <pre class="prettyprint"> |
| 2103 ++NumFuncAddresses; |
| 2104 TypeOf(@fN) = TypeOf(TypeID(i32)); |
| 2105 TypeOfFcn(@fN) = TypeOf(@tT); |
| 2106 |
| 2107 if PN == 0: |
| 2108 DefiningFcnIDs += @FN; |
| 2109 ++NumDefinedFunctionAddresses; |
| 2110 </pre> |
| 2111 <p><strong>Examples</strong>:</p> |
| 2112 <pre class="prettyprint"> |
| 2113 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 2114 48:0| 3: <1, 7> | count 7; |
| 2115 50:4| 3: <7, 32> | @t0 = i32; |
| 2116 53:6| 3: <3> | @t1 = float; |
| 2117 55:4| 3: <4> | @t2 = double; |
| 2118 57:2| 3: <2> | @t3 = void; |
| 2119 59:0| 3: <21, 0, 2, 1> | @t4 = double (float); |
| 2120 63:0| 3: <21, 0, 0, 0, 1, 0, 2>| @t5 = |
| 2121 | | i32 (i32, float, i32, double); |
| 2122 69:2| 3: <21, 0, 3> | @t6 = void (); |
| 2123 72:4| 0: <65534> | } |
| 2124 76:0| 3: <8, 4, 0, 1, 0> | declare external double @f0(float
); |
| 2125 80:6| 3: <8, 5, 0, 1, 0> | declare external |
| 2126 | | i32 @f1(i32, float, i32, double); |
| 2127 85:4| 3: <8, 6, 0, 0, 0> | define external void @f2(); |
| 2128 </pre> |
| 2129 <h2 id="constants-blocks"><span id="link-for-constants-block-section"></span>Con
stants Blocks</h2> |
| 2130 <p>Constants blocks define literal constants used within each function. Its inte
nt |
| 2131 it to define them once, before instructions. A constants block can only appear |
| 2132 in a <a class="reference internal" href="#link-for-function-blocks-section"><em>
function block</em></a>, and must appear |
| 2133 before any instructions in the function block.</p> |
| 2134 <p>Currently, only integer literals, floating point literals, and undefined vect
or |
| 2135 constants can be defined.</p> |
| 2136 <p>To minimize type information put in a constants block, the type information i
s |
| 2137 separated from the constants. This allows a sequence of constants to be given |
| 2138 the same type. This is done by defining a <a class="reference internal" href="#l
ink-for-constants-set-type-record"><em>set type |
| 2139 record</em></a>, followed by a sequence of literal |
| 2140 constants. These literal constants all get converted to the type of the |
| 2141 preceding set type record.</p> |
| 2142 <p>Note that constants that are used for switch case selectors should not be add
ed |
| 2143 to the constants block, since the switch instruction contains the constants used |
| 2144 for case selectors. All other constants in the function block must be put into a |
| 2145 constants block, so that instructions can use them.</p> |
| 2146 <p>To make this more concrete, consider the following example constants block:</
p> |
| 2147 <pre class="prettyprint"> |
| 2148 106:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 2149 116:0| 3: <1, 0> | i32: |
| 2150 118:4| 3: <4, 2> | %c0 = i32 1; |
| 2151 121:0| 3: <4, 4> | %c1 = i32 2; |
| 2152 123:4| 3: <1, 2> | i8: |
| 2153 126:0| 3: <4, 8> | %c2 = i8 4; |
| 2154 128:4| 3: <4, 6> | %c3 = i8 3; |
| 2155 131:0| 3: <1, 1> | float: |
| 2156 133:4| 3: <6, 1065353216> | %c4 = float 1; |
| 2157 139:6| 0: <65534> | } |
| 2158 </pre> |
| 2159 <h3 id="set-type-record"><span id="link-for-constants-set-type-record"></span>Se
t Type Record</h3> |
| 2160 <p>The <em>set type</em> record defines the type to use for the (immediately) su
cceeding |
| 2161 literals.</p> |
| 2162 <p><strong>Syntax</strong>:</p> |
| 2163 <pre class="prettyprint"> |
| 2164 T: <A> |
| 2165 </pre> |
| 2166 <p><strong>Record</strong>:</p> |
| 2167 <pre class="prettyprint"> |
| 2168 AA: <1, TT> |
| 2169 </pre> |
| 2170 <p><strong>Semantics</strong>:</p> |
| 2171 <p>The <em>set type</em> record defines type <code>T</code> to be used to type t
he (immediately) |
| 2172 succeeding literals. <code>T</code> must be a non-void primitive value type or a
vector |
| 2173 type.</p> |
| 2174 <p><strong>Constraints</strong>:</p> |
| 2175 <pre class="prettyprint"> |
| 2176 TT == TypeID(T) |
| 2177 </pre> |
| 2178 <p><strong>Updates</strong>:</p> |
| 2179 <pre class="prettyprint"> |
| 2180 ConstantsSetType = T; |
| 2181 </pre> |
| 2182 <p><strong>Examples</strong>:</p> |
| 2183 <pre class="prettyprint"> |
| 2184 106:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 2185 116:0| 3: <1, 0> | i32: |
| 2186 118:4| 3: <4, 2> | %c0 = i32 1; |
| 2187 121:0| 3: <4, 4> | %c1 = i32 2; |
| 2188 123:4| 3: <1, 2> | i8: |
| 2189 126:0| 3: <4, 8> | %c2 = i8 4; |
| 2190 128:4| 3: <4, 6> | %c3 = i8 3; |
| 2191 131:0| 3: <1, 1> | float: |
| 2192 133:4| 3: <6, 1065353216> | %c4 = float 1; |
| 2193 139:6| 0: <65534> | } |
| 2194 </pre> |
| 2195 <h3 id="undefined-literal"><span id="link-for-undefined-literal"></span>Undefine
d Literal</h3> |
| 2196 <p>The <em>undefined</em> literal record creates an undefined literal for the ty
pe <em>T</em> |
| 2197 defined by the preceding <em>set type</em> record.</p> |
| 2198 <p>Note: See <a class="reference internal" href="#link-for-insert-element-instru
ction-section"><em>insert element |
| 2199 instruction</em></a> for an example of how |
| 2200 you would use the undefined literal with vector types.</p> |
| 2201 <p><strong>Syntax</strong>:</p> |
| 2202 <pre class="prettyprint"> |
| 2203 %cN = T undef; <50> |
| 2204 </pre> |
| 2205 <p><strong>Record</strong>:</p> |
| 2206 <pre class="prettyprint"> |
| 2207 AA: <3> |
| 2208 </pre> |
| 2209 <p><strong>Semantics</strong>:</p> |
| 2210 <p>The <em>undefined</em> literal record creates an undefined literal constant <
code>%cN</code> for |
| 2211 type <code>T</code>. <code>T</code> must be the type defined by the preceding <
em>set type</em> record, and |
| 2212 be a primitive value type or a vector type.</p> |
| 2213 <p><strong>Constraints</strong>:</p> |
| 2214 <pre class="prettyprint"> |
| 2215 N == NumFcnConsts & |
| 2216 T == ConstantsSetType & |
| 2217 IsPrimitive(T) or IsVector(T) |
| 2218 </pre> |
| 2219 <p><strong>Updates</strong>:</p> |
| 2220 <pre class="prettyprint"> |
| 2221 ++NumFcnConsts; |
| 2222 TypeOf(%cN) = T; |
| 2223 </pre> |
| 2224 <p><strong>Examples</strong>:</p> |
| 2225 <pre class="prettyprint"> |
| 2226 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 2227 48:0| 3: <1, 5> | count 5; |
| 2228 50:4| 3: <7, 32> | @t0 = i32; |
| 2229 53:6| 3: <3> | @t1 = float; |
| 2230 55:4| 3: <2> | @t2 = void; |
| 2231 57:2| 3: <12, 4, 0> | @t3 = <4 x i32>; |
| 2232 60:4| 3: <21, 0, 2> | @t4 = void (); |
| 2233 63:6| 0: <65534> | } |
| 2234 ... |
| 2235 106:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 2236 116:0| 3: <1, 0> | i32: |
| 2237 118:4| 3: <3> | %c0 = i32 undef; |
| 2238 120:2| 3: <4, 2> | %c1 = i32 1; |
| 2239 122:6| 3: <1, 3> | <4 x i32>: |
| 2240 125:2| 3: <3> | %c2 = <4 x i32> undef; |
| 2241 127:0| 3: <1, 1> | float: |
| 2242 129:4| 3: <3> | %c3 = float undef; |
| 2243 131:2| 0: <65534> | } |
| 2244 </pre> |
| 2245 <h3 id="integer-literal"><span id="link-for-integer-literal"></span>Integer Lite
ral</h3> |
| 2246 <p>The <em>integer literal</em> record creates an integer literal for the intege
r type <em>T</em> |
| 2247 defined by the preceding <em>set type</em> record.</p> |
| 2248 <p><strong>Syntax</strong>:</p> |
| 2249 <pre class="prettyprint"> |
| 2250 %cN = T V; <A> |
| 2251 </pre> |
| 2252 <p><strong>Record</strong>:</p> |
| 2253 <pre class="prettyprint"> |
| 2254 AA: <4, VV> |
| 2255 </pre> |
| 2256 <p><strong>Semantics</strong>:</p> |
| 2257 <p>The <em>integer literal</em> record creates an integer literal constant <code
>%cN</code> for |
| 2258 type <code>T</code>. <code>T</code> must be the type defined by the preceding <
em>set type</em> record, |
| 2259 and an integer type. The literal <code>V</code> can be signed, but must be defin
able by |
| 2260 type <code>T</code>.</p> |
| 2261 <p><strong>Constraints</strong>:</p> |
| 2262 <pre class="prettyprint"> |
| 2263 N == NumFcnConsts & |
| 2264 T == ConstantsSetType & |
| 2265 VV == SignRotate(V) & |
| 2266 IsInteger(T) |
| 2267 </pre> |
| 2268 <p><strong>Updates</strong>:</p> |
| 2269 <pre class="prettyprint"> |
| 2270 TypeOf(%cN) = T; |
| 2271 </pre> |
| 2272 <p><strong>Examples</strong>:</p> |
| 2273 <pre class="prettyprint"> |
| 2274 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 2275 48:0| 3: <1, 7> | count 7; |
| 2276 50:4| 3: <7, 8> | @t0 = i8; |
| 2277 53:0| 3: <7, 16> | @t1 = i16; |
| 2278 55:4| 3: <7, 32> | @t2 = i32; |
| 2279 58:6| 3: <7, 64> | @t3 = i64; |
| 2280 62:0| 3: <7, 1> | @t4 = i1; |
| 2281 64:4| 3: <2> | @t5 = void; |
| 2282 66:2| 3: <21, 0, 5> | @t6 = void (); |
| 2283 69:4| 0: <65534> | } |
| 2284 ... |
| 2285 114:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 2286 124:0| 3: <1, 0> | i8: |
| 2287 126:4| 3: <4, 2> | %c0 = i8 1; |
| 2288 129:0| 3: <4, 4> | %c1 = i8 2; |
| 2289 131:4| 3: <1, 1> | i16: |
| 2290 134:0| 3: <4, 6> | %c2 = i16 3; |
| 2291 136:4| 3: <4, 8> | %c3 = i16 4; |
| 2292 139:0| 3: <1, 2> | i32: |
| 2293 141:4| 3: <4, 10> | %c4 = i32 5; |
| 2294 144:0| 3: <4, 12> | %c5 = i32 6; |
| 2295 146:4| 3: <1, 3> | i64: |
| 2296 149:0| 3: <4, 3> | %c6 = i64 -1; |
| 2297 151:4| 3: <4, 5> | %c7 = i64 -2; |
| 2298 154:0| 3: <1, 4> | i1: |
| 2299 156:4| 3: <4, 3> | %c8 = i1 1; |
| 2300 159:0| 3: <4, 0> | %c9 = i1 0; |
| 2301 161:4| 0: <65534> | } |
| 2302 </pre> |
| 2303 <h3 id="floating-point-literal">Floating Point Literal</h3> |
| 2304 <p>The <em>floating point literal</em> record creates a floating point literal f
or the |
| 2305 floating point type <em>T</em> defined by the preceding <em>set type</em> record
.</p> |
| 2306 <p><strong>Syntax</strong>:</p> |
| 2307 <pre class="prettyprint"> |
| 2308 %cN = T V; <A> |
| 2309 </pre> |
| 2310 <p><strong>Record</strong>:</p> |
| 2311 <pre class="prettyprint"> |
| 2312 AA: <6, VV> |
| 2313 </pre> |
| 2314 <p><strong>Semantics</strong>:</p> |
| 2315 <p>The <em>floating point literal</em> record creates a floating point literal c
onstant |
| 2316 <code>%cN</code> for type <code>T</code>. <code>T</code> must the type type defi
ned by the preceding <em>set |
| 2317 type</em> record, and be a floating point type. The literal <code>V</code> is th
e floating |
| 2318 value to be defined. The value <code>VV</code> if the corresponding IEEE unsigne
d integer |
| 2319 that defines value <code>V</code>. That is, the literal <code>VV</code> must be
a valid IEE 754 |
| 2320 32-bit (unsigned integer) value if <code>T</code> is <code>float</code>, and a v
alid IEEE 754 |
| 2321 64-bit (unsigned integer) value if <code>T</code> is <code>double</code>.</p> |
| 2322 <p><strong>Constraints</strong>:</p> |
| 2323 <pre class="prettyprint"> |
| 2324 N == NumFcnConsts |
| 2325 T == ConstantsSetType |
| 2326 IsFloat(T) |
| 2327 </pre> |
| 2328 <p><strong>Updates</strong>:</p> |
| 2329 <pre class="prettyprint"> |
| 2330 TypeOf(%cN) = T; |
| 2331 </pre> |
| 2332 <p><strong>Examples</strong>:</p> |
| 2333 <pre class="prettyprint"> |
| 2334 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 2335 48:0| 3: <1, 4> | count 4; |
| 2336 50:4| 3: <3> | @t0 = float; |
| 2337 52:2| 3: <4> | @t1 = double; |
| 2338 54:0| 3: <2> | @t2 = void; |
| 2339 55:6| 3: <21, 0, 2> | @t3 = void (); |
| 2340 59:0| 0: <65534> | } |
| 2341 ... |
| 2342 102:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 2343 112:0| 3: <1, 0> | float: |
| 2344 114:4| 3: <6, 0> | %c0 = float 0; |
| 2345 117:0| 3: <6, 1065353216> | %c1 = float 1; |
| 2346 123:2| 3: <6, 1088421888> | %c2 = float 7; |
| 2347 130:2| 3: <6, 1090519040> | %c3 = float 8; |
| 2348 137:2| 3: <3> | %c4 = float undef; |
| 2349 139:0| 3: <6, 2143289344> | %c5 = float nan; |
| 2350 146:0| 3: <6, 2139095040> | %c6 = float inf; |
| 2351 153:0| 3: <6, 4286578688> | %c7 = float -inf; |
| 2352 160:0| 3: <1, 1> | double: |
| 2353 162:4| 3: <6, | %c8 = double 1; |
| 2354 | 4607182418800017408> | |
| 2355 174:0| 3: <6, 0> | %c9 = double 0; |
| 2356 176:4| 3: <6, | %c10 = double 5; |
| 2357 | 4617315517961601024> | |
| 2358 188:0| 3: <6, | %c11 = double 6; |
| 2359 | 4618441417868443648> | |
| 2360 199:4| 3: <6, | %c12 = double nan; |
| 2361 | 9221120237041090560> | |
| 2362 211:0| 3: <6, | %c13 = double inf; |
| 2363 | 9218868437227405312> | |
| 2364 222:4| 3: <6, | %c14 = double -inf; |
| 2365 | 18442240474082181120>| |
| 2366 234:0| 0: <65534> | } |
| 2367 </pre> |
| 2368 <h2 id="function-blocks"><span id="link-for-function-blocks-section"></span>Func
tion Blocks</h2> |
| 2369 <p>A function block defines the implementation of a defined <a class="reference
internal" href="#link-for-function-address-section"><em>function |
| 2370 address</em></a>. The function address it defines is |
| 2371 based on the position of the corresponding defined function address. The Nth |
| 2372 defined function address always corresponds to the Nth function block in the |
| 2373 module block.</p> |
| 2374 <p>A function implementation contains a list of basic blocks, forming the contro
l |
| 2375 flow graph. Each <em>basic block</em> contains a list of instructions, and ends
with a |
| 2376 <a class="reference internal" href="#link-for-terminator-instruction-section"><e
m>terminator instruction</em></a> |
| 2377 (e.g. branch).</p> |
| 2378 <p>Basic blocks are not represented by records. Rather, context is implicit. The |
| 2379 first basic block begins with the first instruction record in the function |
| 2380 block. Block boundaries are determined by terminator instructions. The |
| 2381 instruction that follows a terminator instruction begins a new basic block.</p> |
| 2382 <p>The first basic block in a function is special in two ways: it is immediately |
| 2383 executed on entrance to the function, and it is not allowed to have predecessor |
| 2384 basic blocks (i.e. there can’t be any branches to the entry block of a |
| 2385 function). Because the entry block has no predecessors, it also can’t have
any |
| 2386 <a class="reference internal" href="#link-for-phi-instruction-section"><em>phi</
em></a> instructions.</p> |
| 2387 <p>The parameters are implied by the type of the corresponding function |
| 2388 address. One parameter is defined for each argument of the function <a class="re
ference internal" href="#link-for-function-type"><em>type |
| 2389 signature</em></a> of the corresponding <a class="reference internal" href="#lin
k-for-function-address-section"><em>function |
| 2390 address</em></a>.</p> |
| 2391 <p>The number of basic blocks is defined by the <a class="reference internal" hr
ef="#link-for-basic-blocks-count"><em>count |
| 2392 record</em></a>. Each ::ref::<cite>terminator |
| 2393 instruction<link_for_terminator_instruction_section></cite> ends the curre
nt basic |
| 2394 block, and the next instruction begins a new basic block. Basic blocks are |
| 2395 numbered by the order they appear (starting with index 0). Basic block IDs have |
| 2396 the form <code>%bN</code>, where <code>N</code> corresponds to the position of t
he basic block |
| 2397 within the function block.</p> |
| 2398 <p>Each instruction, within a function block, corresponds to a corresponding PNa
Cl |
| 2399 record. The layout of a function block is the (basic block) count record, |
| 2400 followed by a sequence of instruction records.</p> |
| 2401 <p>For readability, PNaClAsm introduces basic block IDs. These basic block IDs d
o |
| 2402 not correspond to PNaCl records, since basic block boundaries are defined |
| 2403 implicitly, after terminator instructions. They appear only for readability.</p> |
| 2404 <p>Operands of instructions are defined using an <a class="reference internal" h
ref="#link-for-absolute-index-section"><em>absolute |
| 2405 index</em></a>. This absolute index implicitly encodes |
| 2406 function addresses, global addresses, parameters, constants, and instructions |
| 2407 that generate values. The encoding takes advantage of the implied ordering of |
| 2408 these values in the bitcode file, defining a contiguous sequence of indices for |
| 2409 each kind of identifier. That is, indices are ordered by putting function |
| 2410 address identifiers first, followed by global address identifiers, followed by |
| 2411 parameter identifiers, followed by constant identifiers, and lastly instruction |
| 2412 value identifiers.</p> |
| 2413 <p>To save space in the encoded bitcode file, most operands are encoded using a |
| 2414 <a class="reference internal" href="#link-for-relative-index"><em>relative index
</em></a> value, rather than |
| 2415 <a class="reference internal" href="#link-for-absolute-index-section"><em>absolu
te</em></a>. This |
| 2416 is done because most instruction operands refer to values defined earlier in the |
| 2417 (same) basic block. As a result, the relative distance (back) from the next |
| 2418 value defining instruction is frequently a small number. Small numbers tend to |
| 2419 require fewer bits when they are converted to bit sequences.</p> |
| 2420 <p>Note that instructions that can appear in a function block are defined in sec
tions |
| 2421 <a class="reference internal" href="#link-for-terminator-instruction-section"><e
m>Terminator Instructions</em></a>, |
| 2422 <a class="reference internal" href="#link-for-integer-binary-instructions"><em>I
nteger Binary Instructions</em></a>, |
| 2423 <a class="reference internal" href="#link-for-floating-point-binary-instructions
"><em>Floating Point Binary Instructions</em></a>, |
| 2424 <a class="reference internal" href="#link-for-memory-creation-and-access-instruc
tions"><em>Memory Creation and Access Instructions</em></a>, |
| 2425 <a class="reference internal" href="#link-for-conversion-instructions"><em>Conve
rsion Instructions</em></a>, |
| 2426 <a class="reference internal" href="#link-for-compare-instructions"><em>Comparis
on Instructions</em></a>, |
| 2427 <a class="reference internal" href="#link-for-vector-instructions"><em>Vector In
structions</em></a>, and |
| 2428 <a class="reference internal" href="#link-for-other-pnaclasm-instructions"><em>O
ther Instructions</em></a>.</p> |
| 2429 <p>The following subsections define the remaining records that can appear in a |
| 2430 function block.</p> |
| 2431 <h3 id="function-enter">Function Enter</h3> |
| 2432 <p>PNaClAsm defines a function enter block construct. The corresponding record i
s |
| 2433 simply an <a class="reference internal" href="#link-for-enter-block-record-secti
on"><em>enter block</em></a> record, with |
| 2434 BlockID value <code>12</code>. All context about the defining address is implici
t by the |
| 2435 position of the function block, and the corresponding defining <a class="referen
ce internal" href="#link-for-function-address-section"><em>function |
| 2436 address</em></a>. To improve readability, PNaClAsm |
| 2437 includes the function signature into the syntax rule.</p> |
| 2438 <p><strong>Syntax</strong>:</p> |
| 2439 <pre class="prettyprint"> |
| 2440 function TR @fN ( T0 %p0, ... , TM %pM ) { <B> |
| 2441 </pre> |
| 2442 <p><strong>Record</strong>:</p> |
| 2443 <pre class="prettyprint"> |
| 2444 1: <65535, 12, B> |
| 2445 </pre> |
| 2446 <p><strong>Semantics</strong>:</p> |
| 2447 <p><code>B</code> is the number of bits reserved for abbreviations in the block.
If it is |
| 2448 omitted, 2 is assumed. See <a class="reference internal" href="#link-for-enter-b
lock-record-section"><em>enter</em></a> |
| 2449 block records for more details.</p> |
| 2450 <p>The value of <code>N</code> corresponds to the positional index of the corres
ponding |
| 2451 defining function address this block is associated with. <code>M</code> is the n
umber of |
| 2452 defined parameters (minus one) in the function heading.</p> |
| 2453 <p><strong>Constraints</strong>:</p> |
| 2454 <pre class="prettyprint"> |
| 2455 N == NumFcnImpls & |
| 2456 @fN in DefiningFcnIDs & |
| 2457 TypeOfFcn(@fN) == TypeOf(TypeID(TR (T0, ... , TM))) |
| 2458 </pre> |
| 2459 <p><strong>Updates</strong>:</p> |
| 2460 <pre class="prettyprint"> |
| 2461 ++NumFcnImpls; |
| 2462 EnclosingFcnID = @fN; |
| 2463 NumBasicBlocks = 0; |
| 2464 ExpectedBlocks = 0; |
| 2465 NumParams = M; |
| 2466 for I in [0..M]: |
| 2467 TypeOf(%pI) = TypeOf(TypeID(TI)); |
| 2468 </pre> |
| 2469 <p><strong>Examples</strong>:</p> |
| 2470 <pre class="prettyprint"> |
| 2471 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 2472 48:0| 3: <1, 4> | count 4; |
| 2473 50:4| 3: <7, 32> | @t0 = i32; |
| 2474 53:6| 3: <2> | @t1 = void; |
| 2475 55:4| 3: <21, 0, 1> | @t2 = void (); |
| 2476 58:6| 3: <21, 0, 0, 0> | @t3 = i32 (i32); |
| 2477 62:6| 0: <65534> | } |
| 2478 ... |
| 2479 104:0| 1: <65535, 12, 2> | function void @f0() { |
| 2480 | | // BlockID = 12 |
| 2481 112:0| 3: <1, 1> | blocks 1; |
| 2482 | | %b0: |
| 2483 114:4| 3: <10> | ret void; |
| 2484 116:2| 0: <65534> | } |
| 2485 120:0| 1: <65535, 12, 2> | function i32 @f1(i32 %p0) { |
| 2486 | | // BlockID = 12 |
| 2487 128:0| 3: <1, 1> | blocks 1; |
| 2488 | | %b0: |
| 2489 130:4| 3: <10, 1> | ret i32 %p0; |
| 2490 133:0| 0: <65534> | } |
| 2491 </pre> |
| 2492 <h3 id="link-for-basic-blocks-count"><span id="id3"></span>Count Record</h3> |
| 2493 <p>The count record, within a function block, defines the number of basic blocks |
| 2494 used to define the function implementation. It must be the first record in the |
| 2495 function block.</p> |
| 2496 <p><strong>Syntax</strong>:</p> |
| 2497 <pre class="prettyprint"> |
| 2498 blocks: N; <A> |
| 2499 %b0: |
| 2500 </pre> |
| 2501 <p><strong>Record</strong>:</p> |
| 2502 <pre class="prettyprint"> |
| 2503 AA: <1, N> |
| 2504 </pre> |
| 2505 <p><strong>Semantics</strong>:</p> |
| 2506 <p>The count record defines the number <code>N</code> of basic blocks in the imp
lemented |
| 2507 function.</p> |
| 2508 <p><strong>Constraints</strong>:</p> |
| 2509 <pre class="prettyprint"> |
| 2510 AA == AbbrevIndex(A) & |
| 2511 ExpectedBasicBlocks == N & |
| 2512 NumBasicBlocks == 0 |
| 2513 </pre> |
| 2514 <p><strong>Updates</strong>:</p> |
| 2515 <pre class="prettyprint"> |
| 2516 104:0| 1: <65535, 12, 2> | function void @f0() { |
| 2517 | | // BlockID = 12 |
| 2518 112:0| 3: <1, 1> | blocks 1; |
| 2519 | | %b0: |
| 2520 114:4| 3: <10> | ret void; |
| 2521 116:2| 0: <65534> | } |
| 2522 120:0| 1: <65535, 12, 2> | function i32 @f1(i32 %p0) { |
| 2523 | | // BlockID = 12 |
| 2524 128:0| 3: <1, 1> | blocks 1; |
| 2525 | | %b0: |
| 2526 130:4| 3: <10, 1> | ret i32 %p0; |
| 2527 133:0| 0: <65534> | } |
| 2528 </pre> |
| 2529 <h2 id="terminator-instructions"><span id="link-for-terminator-instruction-secti
on"></span>Terminator Instructions</h2> |
| 2530 <p>Terminator instructions are instructions that appear in a <a class="reference
internal" href="#link-for-function-blocks-section"><em>function |
| 2531 block</em></a>, and define the end of the current |
| 2532 basic block. A terminator instruction indicates which block should be executed |
| 2533 after the current block is finished. The function block is well formed only if |
| 2534 the number of terminator instructions, in the function block, corresponds to the |
| 2535 value defined by the corresponding function basic block <a class="reference inte
rnal" href="#link-for-basic-blocks-count"><em>count |
| 2536 record</em></a>.</p> |
| 2537 <p>Note that any branch instruction to label <code>%bN</code>, where <code>N >
;= |
| 2538 ExpectedBasicBlocks</code>, is illegal. For ease of readability, this constraint |
| 2539 hasn’t been put on branch instructions. Rather it is only implied.</p> |
| 2540 <p>In addition, it must be the case that <code>NumBasicBlocks < ExpectedBasic
Blocks</code>, |
| 2541 and will not be listed as a constraint. Further, if <code>B = NumBasicBlocks + 1
</code> |
| 2542 is the number associated with the next basic block. Label <cite>%bB:</cite> onl
y appears |
| 2543 if:</p> |
| 2544 <pre class="prettyprint"> |
| 2545 B < ExpectedBasicBlocks |
| 2546 </pre> |
| 2547 <p>That is, the label is omitted only if this terminator instruction is the last |
| 2548 instruction in the function block.</p> |
| 2549 <h3 id="return-void-instruction">Return Void Instruction</h3> |
| 2550 <p>The return void instruction is used to return control from a function back to |
| 2551 the caller, without returning any value.</p> |
| 2552 <p><strong>Syntax</strong>:</p> |
| 2553 <pre class="prettyprint"> |
| 2554 ret void; <A> |
| 2555 %bB: |
| 2556 </pre> |
| 2557 <p><strong>Record</strong>:</p> |
| 2558 <pre class="prettyprint"> |
| 2559 AA: <10> |
| 2560 </pre> |
| 2561 <p><strong>Semantics</strong>:</p> |
| 2562 <p>The return void instruction returns control to the calling function.</p> |
| 2563 <p><strong>Constraints</strong>:</p> |
| 2564 <pre class="prettyprint"> |
| 2565 AA == AbbrevIndex(A) & |
| 2566 B == NumBasicBlocks + 1 & |
| 2567 ReturnType(TypeOf(EnclosingFcnID)) == void |
| 2568 </pre> |
| 2569 <p><strong>Updates</strong>:</p> |
| 2570 <pre class="prettyprint"> |
| 2571 ++NumBasicBlocks; |
| 2572 </pre> |
| 2573 <p><strong>Examples</strong>:</p> |
| 2574 <pre class="prettyprint"> |
| 2575 104:0| 1: <65535, 12, 2> | function void @f0() { |
| 2576 | | // BlockID = 12 |
| 2577 112:0| 3: <1, 1> | blocks 1; |
| 2578 | | %b0: |
| 2579 114:4| 3: <10> | ret void; |
| 2580 116:2| 0: <65534> | } |
| 2581 </pre> |
| 2582 <h3 id="return-value-instruction">Return Value Instruction</h3> |
| 2583 <p>The return value instruction is used to return control from a function back t
o |
| 2584 the caller, including a value. The value must correspond to the return type of |
| 2585 the enclosing function.</p> |
| 2586 <p><strong>Syntax</strong>:</p> |
| 2587 <pre class="prettyprint"> |
| 2588 ret T V; <A> |
| 2589 %bB: |
| 2590 </pre> |
| 2591 <p><strong>Record</strong>:</p> |
| 2592 <pre class="prettyprint"> |
| 2593 AA: <10, VV> |
| 2594 </pre> |
| 2595 <p><strong>Semantics</strong>:</p> |
| 2596 <p>The return value instruction returns control to the calling function, returni
ng |
| 2597 the provided value.</p> |
| 2598 <p><code>V</code> is the value to return. Type <code>T</code> must be of the typ
e returned by the |
| 2599 function. It must also be the type associated with value <code>V</code>.</p> |
| 2600 <p>The return type <code>T</code> must either be a (non-void) primitive type, or
a vector |
| 2601 type. If the function block is implementing an ordinary function, and the return |
| 2602 type is an integer type, it must be either <code>i32</code> or <code>i64</code>.
</p> |
| 2603 <p><strong>Constraints</strong>:</p> |
| 2604 <pre class="prettyprint"> |
| 2605 AA == AbbrevIndex(A) & |
| 2606 VV == RelativeIndex(V) & |
| 2607 B == NumBasicBlocks + 1 & |
| 2608 T == TypeOf(V) == ReturnType(TypeOf(EnclosingFcnID)) |
| 2609 </pre> |
| 2610 <p><strong>Updates</strong>:</p> |
| 2611 <pre class="prettyprint"> |
| 2612 ++NumBasicBlocks; |
| 2613 </pre> |
| 2614 <p><strong>Examples</strong>:</p> |
| 2615 <pre class="prettyprint"> |
| 2616 120:0| 1: <65535, 12, 2> | function i32 @f1(i32 %p0) { |
| 2617 | | // BlockID = 12 |
| 2618 128:0| 3: <1, 1> | blocks 1; |
| 2619 | | %b0: |
| 2620 130:4| 3: <10, 1> | ret i32 %p0; |
| 2621 </pre> |
| 2622 <h3 id="unconditional-branch-instruction">Unconditional Branch Instruction</h3> |
| 2623 <p>The unconditional branch instruction is used to cause control flow to transfe
r |
| 2624 to a different basic block of the function.</p> |
| 2625 <p><strong>Syntax</strong>:</p> |
| 2626 <pre class="prettyprint"> |
| 2627 br %bN; <A> |
| 2628 %bB: |
| 2629 </pre> |
| 2630 <p><strong>Record</strong>:</p> |
| 2631 <pre class="prettyprint"> |
| 2632 AA: <11, N> |
| 2633 </pre> |
| 2634 <p><strong>Semantics</strong>:</p> |
| 2635 <p>The unconditional branch instruction causes control flow to transfer to basic |
| 2636 block <code>N</code>.</p> |
| 2637 <p><strong>Constraints</strong>:</p> |
| 2638 <pre class="prettyprint"> |
| 2639 AA == AbbrevIndex(A) & |
| 2640 B == NumBasicBlocks + 1 & |
| 2641 0 < N & |
| 2642 N < ExpectedBasicBlocks |
| 2643 </pre> |
| 2644 <p><strong>Updates</strong>:</p> |
| 2645 <pre class="prettyprint"> |
| 2646 ++NumBasicBlocks; |
| 2647 </pre> |
| 2648 <p><strong>Examples</strong>:</p> |
| 2649 <pre class="prettyprint"> |
| 2650 88:0| 1: <65535, 12, 2> | function void @f0() { |
| 2651 | | // BlockID = 12 |
| 2652 96:0| 3: <1, 5> | blocks 5; |
| 2653 | | %b0: |
| 2654 98:4| 3: <11, 3> | br label %b3; |
| 2655 | | %b1: |
| 2656 101:0| 3: <11, 4> | br label %b4; |
| 2657 | | %b2: |
| 2658 103:4| 3: <11, 1> | br label %b1; |
| 2659 | | %b3: |
| 2660 106:0| 3: <11, 2> | br label %b2; |
| 2661 | | %b4: |
| 2662 108:4| 3: <10> | ret void; |
| 2663 110:2| 0: <65534> | } |
| 2664 </pre> |
| 2665 <h3 id="conditional-branch-instruction">Conditional Branch Instruction</h3> |
| 2666 <p>The conditional branch instruction is used to cause control flow to transfer
to |
| 2667 a different basic block of the function, based on a boolean test condition.</p> |
| 2668 <p><strong>Syntax</strong>:</p> |
| 2669 <pre class="prettyprint"> |
| 2670 br i1 C, %bT, %bBF; <A> |
| 2671 %bB: |
| 2672 </pre> |
| 2673 <p><strong>Record</strong>:</p> |
| 2674 <pre class="prettyprint"> |
| 2675 AA: <11, T, F, CC> |
| 2676 </pre> |
| 2677 <p><strong>Semantics</strong>:</p> |
| 2678 <p>Upon execution of a conditional branch instruction, the <em>i1</em> (boolean)
argument |
| 2679 <code>C</code> is evaluated. If the value is <code>true</code>, control flows to
basic block |
| 2680 <code>%bT</code>. Otherwise control flows to basic block <code>%bF</code>.</p> |
| 2681 <p><strong>Constraints</strong>:</p> |
| 2682 <pre class="prettyprint"> |
| 2683 AA == AbbrevIndex(A) & |
| 2684 CC == RelativeIndex(C) & |
| 2685 B == NumBasicBlocks + 1 & |
| 2686 0 < T & |
| 2687 B1 < ExpectedBasicBlocks & |
| 2688 0 < F & |
| 2689 B2 < ExpectedBasicBlocks & |
| 2690 TypeOf(C) == i1 |
| 2691 </pre> |
| 2692 <p><strong>Updates</strong>:</p> |
| 2693 <pre class="prettyprint"> |
| 2694 ++NumBasicBlocks; |
| 2695 </pre> |
| 2696 <p><strong>Examples</strong>:</p> |
| 2697 <pre class="prettyprint"> |
| 2698 92:0| 1: <65535, 12, 2> | function void @f0() { |
| 2699 | | // BlockID = 12 |
| 2700 100:0| 3: <1, 5> | blocks 5; |
| 2701 102:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 2702 112:0| 3: <1, 1> | i1: |
| 2703 114:4| 3: <4, 3> | %c0 = i1 1; |
| 2704 117:0| 3: <4, 0> | %c1 = i1 0; |
| 2705 119:4| 0: <65534> | } |
| 2706 | | %b0: |
| 2707 120:0| 3: <11, 3> | br label %b3; |
| 2708 | | %b1: |
| 2709 122:4| 3: <11, 2, 4, 2> | br i1 %c0, label %b2, label %b4; |
| 2710 | | %b2: |
| 2711 126:4| 3: <11, 3> | br label %b3; |
| 2712 | | %b3: |
| 2713 129:0| 3: <10> | ret void; |
| 2714 | | %b4: |
| 2715 130:6| 3: <11, 2, 3, 1> | br i1 %c1, label %b2, label %b3; |
| 2716 134:6| 0: <65534> | } |
| 2717 </pre> |
| 2718 <h3 id="unreachable">Unreachable</h3> |
| 2719 <p>The unreachable instruction has no defined semantics. The instruction is used
to |
| 2720 inform the <a class="reference internal" href="/native-client/overview.html#link
-for-pnacl-translator"><em>PNaCl translator</em></a> that control |
| 2721 can’t reach this instruction.</p> |
| 2722 <p><strong>Syntax</strong>:</p> |
| 2723 <pre class="prettyprint"> |
| 2724 unreachable; <A> |
| 2725 %bB: |
| 2726 </pre> |
| 2727 <p><strong>Record</strong>:</p> |
| 2728 <pre class="prettyprint"> |
| 2729 AA: <15> |
| 2730 </pre> |
| 2731 <p><strong>Semantics</strong>:</p> |
| 2732 <p>Directive to the <a class="reference internal" href="/native-client/overview.
html#link-for-pnacl-translator"><em>PNaCl translator</em></a> that |
| 2733 this instruction is unreachable.</p> |
| 2734 <p><strong>Constraints</strong>:</p> |
| 2735 <pre class="prettyprint"> |
| 2736 AA == AbbrevIndex(A) |
| 2737 B == NumBasicBlocks + 1 & |
| 2738 </pre> |
| 2739 <p><strong>Updates</strong>:</p> |
| 2740 <pre class="prettyprint"> |
| 2741 ++NumBasicBlocks; |
| 2742 </pre> |
| 2743 <p><strong>Examples</strong>:</p> |
| 2744 <pre class="prettyprint"> |
| 2745 108:0| 1: <65535, 12, 2> | function void @f0(i32 %p0) { |
| 2746 | | // BlockID = 12 |
| 2747 116:0| 3: <1, 5> | blocks 5; |
| 2748 118:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 2749 128:0| 3: <1, 2> | i1: |
| 2750 130:4| 3: <4, 3> | %c0 = i1 1; |
| 2751 133:0| 3: <4, 0> | %c1 = i1 0; |
| 2752 135:4| 0: <65534> | } |
| 2753 | | %b0: |
| 2754 136:0| 3: <11, 1, 2, 2> | br i1 %c0, label %b1, label %b2; |
| 2755 | | %b1: |
| 2756 140:0| 3: <11, 3, 4, 1> | br i1 %c1, label %b3, label %b4; |
| 2757 | | %b2: |
| 2758 144:0| 3: <15> | unreachable; |
| 2759 | | %b3: |
| 2760 145:6| 3: <15> | unreachable; |
| 2761 | | %b4: |
| 2762 147:4| 3: <10> | ret void; |
| 2763 149:2| 0: <65534> | } |
| 2764 </pre> |
| 2765 <h3 id="switch-instruction">Switch Instruction</h3> |
| 2766 <p>The <em>switch</em> instruction transfers control flow to one of several diff
erent |
| 2767 places, based on a selector value. It is a generalization of the conditional |
| 2768 branch instruction.</p> |
| 2769 <p><strong>Syntax</strong>:</p> |
| 2770 <pre class="prettyprint"> |
| 2771 switch T V0 { |
| 2772 default: br label %bB0; |
| 2773 T V1: br label %bB1; |
| 2774 ... |
| 2775 T VN: br label %bBN; |
| 2776 } <A> |
| 2777 %bB: |
| 2778 </pre> |
| 2779 <p><strong>Record</strong>:</p> |
| 2780 <pre class="prettyprint"> |
| 2781 AA: <12, TT, B0, N, (1, 1, VVI, BI | 1 <= i <= N)> |
| 2782 </pre> |
| 2783 <p><strong>Semantics</strong>:</p> |
| 2784 <p>The switch instruction transfers control to a basic block in <code>B0</code>
through |
| 2785 <code>BN</code>. Value <code>V</code> is used to conditionally select which blo
ck to branch |
| 2786 to. <code>T</code> is the type of <code>V</code> and <code>V1</code> through <co
de>VN</code>, and must be an integer |
| 2787 type. Value <code>V1</code> through <code>VN</code> are integers to compare agai
nst <code>V</code>. If selector |
| 2788 <code>V</code> matches <code>VI</code> (for some <code>I</code>, <code>1 <= I
<= N</code>), then the instruction branches to |
| 2789 block <code>BI</code>. If <code>V</code> is not in <code>V1</code> through <code
>VN</code>, the instruction branches to |
| 2790 block <code>B0</code>.</p> |
| 2791 <p><strong>Constraints</strong>:</p> |
| 2792 <pre class="prettyprint"> |
| 2793 AA == AbbrevIndex(A) & |
| 2794 B == NumBasicBlocks + 1 & |
| 2795 TT == TypeID(T) & |
| 2796 VI == SignRotate(VI) for all I, 1 <= I <= N & |
| 2797 </pre> |
| 2798 <p><strong>Updates</strong>:</p> |
| 2799 <pre class="prettyprint"> |
| 2800 ++NumBasicBlocks; |
| 2801 </pre> |
| 2802 <p><strong>Examples</strong>:</p> |
| 2803 <pre class="prettyprint"> |
| 2804 116:0| 1: <65535, 12, 2> | function void @f0(i32 %p0) { |
| 2805 | | // BlockID = 12 |
| 2806 124:0| 3: <1, 6> | blocks 6; |
| 2807 | | %b0: |
| 2808 126:4| 3: <12, 1, 1, 2, 4, 1, 1,| switch i32 %p0 { |
| 2809 | 2, 3, 1, 1, 4, 3, 1, | default: br label %b2; |
| 2810 | 1, 8, 4, 1, 1, 10, 4>| i32 1: br label %b3; |
| 2811 | | i32 2: br label %b3; |
| 2812 | | i32 4: br label %b4; |
| 2813 | | i32 5: br label %b4; |
| 2814 | | } |
| 2815 | | %b1: |
| 2816 143:2| 3: <11, 5> | br label %b5; |
| 2817 | | %b2: |
| 2818 145:6| 3: <11, 5> | br label %b5; |
| 2819 | | %b3: |
| 2820 148:2| 3: <11, 5> | br label %b5; |
| 2821 | | %b4: |
| 2822 150:6| 3: <11, 5> | br label %b5; |
| 2823 | | %b5: |
| 2824 153:2| 3: <10> | ret void; |
| 2825 155:0| 0: <65534> | } |
| 2826 156:0| 1: <65535, 12, 2> | function void @f1(i64 %p0) { |
| 2827 | | // BlockID = 12 |
| 2828 164:0| 3: <1, 6> | blocks 6; |
| 2829 | | %b0: |
| 2830 166:4| 3: <12, 2, 1, 2, 4, 1, 1,| switch i64 %p0 { |
| 2831 | 2, 3, 1, 1, 4, 3, 1, | default: br label %b2; |
| 2832 | 1, 8, 4, 1, 1, | i64 1: br label %b3; |
| 2833 | 39777555332, 4> | i64 2: br label %b3; |
| 2834 | | i64 4: br label %b4; |
| 2835 | | i64 19888777666: br label %b4; |
| 2836 | | } |
| 2837 | | %b1: |
| 2838 188:4| 3: <11, 5> | br label %b5; |
| 2839 | | %b2: |
| 2840 191:0| 3: <11, 5> | br label %b5; |
| 2841 | | %b3: |
| 2842 193:4| 3: <11, 5> | br label %b5; |
| 2843 | | %b4: |
| 2844 196:0| 3: <11, 5> | br label %b5; |
| 2845 | | %b5: |
| 2846 198:4| 3: <10> | ret void; |
| 2847 200:2| 0: <65534> | } |
| 2848 </pre> |
| 2849 <h2 id="integer-binary-instructions"><span id="link-for-integer-binary-instructi
ons"></span>Integer Binary Instructions</h2> |
| 2850 <p>Binary instructions are used to do most of the computation in a program. This |
| 2851 section focuses on binary instructions that operator on integer values, or |
| 2852 vectors of integer values.</p> |
| 2853 <p>All binary operations require two operands of the same type, execute an |
| 2854 operation on them, and produce a value. The value may represent multiple values |
| 2855 if the type is a vector type. The result value always has the same type as its |
| 2856 operands.</p> |
| 2857 <p>Some integer binary operations can be applied to both signed and unsigned |
| 2858 integers. Others, the sign is significant. In general, if the sign plays a role |
| 2859 in the instruction, the sign information is encoded into the name of the |
| 2860 instruction.</p> |
| 2861 <p>For most binary operations (except some of the logical operations), integer |
| 2862 type i1 is disallowed.</p> |
| 2863 <h3 id="integer-add">Integer Add</h3> |
| 2864 <p>The integer add instruction returns the sum of its two arguments. Both argume
nts |
| 2865 and the result must be of the same type. That type must be integer, or an |
| 2866 integer vector type.</p> |
| 2867 <p><strong>Syntax</strong>:</p> |
| 2868 <pre class="prettyprint"> |
| 2869 %vN = add T V1, V2; <A> |
| 2870 </pre> |
| 2871 <p><strong>Record</strong>:</p> |
| 2872 <pre class="prettyprint"> |
| 2873 AA: <2, VV1, VV2, 0> |
| 2874 </pre> |
| 2875 <p><strong>Semantics</strong>:</p> |
| 2876 <p>The integer add instruction returns the sum of its two arguments. Arguments |
| 2877 <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 |
| 2878 an integer type, or an integer vector type. <code>N</code> is defined by the re
cord |
| 2879 position, defining the corresponding value generated by the instruction.</p> |
| 2880 <p>The result returned is the mathematical result modulo 2<sup>n</sup>, where <c
ode>n</code> is |
| 2881 the bitwidth of the integer result.</p> |
| 2882 <p>Because integers are assumed to use a two’s complement representation, |
| 2883 this instruction is appropriate for both signed and unsigned integers.</p> |
| 2884 <p>In the add instruction, integer type <code>i1</code> (and a vector on integer
type |
| 2885 <code>i1</code>) is disallowed.</p> |
| 2886 <p><strong>Constraints</strong>:</p> |
| 2887 <pre class="prettyprint"> |
| 2888 AA == AbbrevIndex(A) & |
| 2889 VV1 == RelativeIndex(V1) & |
| 2890 VV2 == RelativeIndex(V2) & |
| 2891 T == TypeOf(V1) == TypeOf(V2) & |
| 2892 IsInteger(UnderlyingType(T)) & |
| 2893 UnderlyingType(T) != i1 & |
| 2894 N == NumValuedInsts |
| 2895 </pre> |
| 2896 <p><strong>Updates</strong>:</p> |
| 2897 <pre class="prettyprint"> |
| 2898 ++NumValuedInsts; |
| 2899 TypeOf(%vN) = T |
| 2900 </pre> |
| 2901 <p><strong>Examples</strong>:</p> |
| 2902 <pre class="prettyprint"> |
| 2903 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 2904 | | // BlockID = 12 |
| 2905 104:0| 3: <1, 1> | blocks 1; |
| 2906 | | %b0: |
| 2907 106:4| 3: <2, 2, 1, 0> | %v0 = add i32 %p0, %p1; |
| 2908 110:4| 3: <2, 3, 1, 0> | %v1 = add i32 %p0, %v0; |
| 2909 114:4| 3: <10, 1> | ret i32 %v1; |
| 2910 117:0| 0: <65534> | } |
| 2911 </pre> |
| 2912 <h3 id="integer-subtract">Integer Subtract</h3> |
| 2913 <p>The integer subtract instruction returns the difference of its two arguments. |
| 2914 Both arguments and the result must be of the same type. That type must be |
| 2915 integer, or an integer vector type.</p> |
| 2916 <p>Note: Since there isn’t a negate instruction, subtraction from constant
zero |
| 2917 should be used to negate values.</p> |
| 2918 <p><strong>Syntax</strong>:</p> |
| 2919 <pre class="prettyprint"> |
| 2920 %vN = sub T V1, V2; <A> |
| 2921 </pre> |
| 2922 <p><strong>Record</strong>:</p> |
| 2923 <pre class="prettyprint"> |
| 2924 AA: <2, VV1, VV2, 1> |
| 2925 </pre> |
| 2926 <p><strong>Semantics</strong>:</p> |
| 2927 <p>The integer subtract returns the difference of its two arguments. Arguments <
code>V1</code> |
| 2928 and <code>V2</code>, and the result <code>%vN</code> must be of type <code>T</co
de>. <code>T</code> must be an integer |
| 2929 type, or an integer vector type. <code>N</code> is defined by the record positio
n, |
| 2930 defining the corresponding value generated by the instruction.</p> |
| 2931 <p>The result returned is the mathematical result modulo 2<sup>n</sup>, where <c
ode>n</code> is |
| 2932 the bitwidth of the integer result.</p> |
| 2933 <p>Because integers are assumed to use a two’s complement representation, |
| 2934 this instruction is appropriate for both signed and unsigned integers.</p> |
| 2935 <p>In the subtract instruction, integer type <code>i1</code> (and a vector on in
teger type |
| 2936 <code>i1</code>) is disallowed.</p> |
| 2937 <p><strong>Constraints</strong>:</p> |
| 2938 <pre class="prettyprint"> |
| 2939 AA == AbbrevIndex(A) & |
| 2940 VV1 == RelativeIndex(V1) & |
| 2941 VV2 == RelativeIndex(V2) & |
| 2942 T == TypeOf(V1) == TypeOf(V2) & |
| 2943 IsInteger(UnderlyingType(T)) & |
| 2944 UnderlyingType(T) != i1 & |
| 2945 N == NumValuedInsts |
| 2946 </pre> |
| 2947 <p><strong>Updates</strong>:</p> |
| 2948 <pre class="prettyprint"> |
| 2949 ++NumValuedInsts; |
| 2950 TypeOf(%vN) = T |
| 2951 </pre> |
| 2952 <p><strong>Examples</strong>:</p> |
| 2953 <pre class="prettyprint"> |
| 2954 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 2955 | | // BlockID = 12 |
| 2956 104:0| 3: <1, 1> | blocks 1; |
| 2957 | | %b0: |
| 2958 106:4| 3: <2, 2, 1, 1> | %v0 = sub i32 %p0, %p1; |
| 2959 110:4| 3: <2, 3, 1, 1> | %v1 = sub i32 %p0, %v0; |
| 2960 114:4| 3: <10, 1> | ret i32 %v1; |
| 2961 117:0| 0: <65534> | } |
| 2962 </pre> |
| 2963 <h3 id="integer-multiply">Integer Multiply</h3> |
| 2964 <p>The integer multiply instruction returns the product of its two arguments. B
oth |
| 2965 arguments and the result must be of the same type. That type must be integer, |
| 2966 or an integer based vector type.</p> |
| 2967 <p><strong>Syntax</strong>:</p> |
| 2968 <pre class="prettyprint"> |
| 2969 &vN = mul T V1, V2; <A> |
| 2970 </pre> |
| 2971 <p><strong>Record</strong>:</p> |
| 2972 <pre class="prettyprint"> |
| 2973 AA: <2, VV1, VV2, 2> |
| 2974 </pre> |
| 2975 <p><strong>Semantics</strong>:</p> |
| 2976 <p>The integer multiply instruction returns the product of its two |
| 2977 arguments. Arguments <code>V1</code> and <code>V2</code>, and the result <code>%
vN</code>, must be of type |
| 2978 <code>T</code>. <code>T</code> must be an integer type, or an integer vector ty
pe. <code>N</code> is |
| 2979 defined by the record position, defining the corresponding value generated by |
| 2980 the instruction.</p> |
| 2981 <p>The result returned is the mathematical result modulo 2<sup>n</sup>, where <c
ode>n</code> is |
| 2982 the bitwidth of the integer result.</p> |
| 2983 <p>Because integers are assumed to use a two’s complement representation, |
| 2984 this instruction is appropriate for both signed and unsigned integers.</p> |
| 2985 <p>In the subtract instruction, integer type <code>i1</code> (or a vector on int
eger type |
| 2986 <code>i1</code>) is disallowed.</p> |
| 2987 <p><strong>Constraints</strong>:</p> |
| 2988 <pre class="prettyprint"> |
| 2989 AA == AbbrevIndex(A) & |
| 2990 VV1 == RelativeIndex(V1) & |
| 2991 VV2 == RelativeIndex(V2) & |
| 2992 T == TypeOf(V1) == TypeOf(V2) & |
| 2993 IsInteger(UnderlyingType(T)) & |
| 2994 UnderlyingType(T) != i1 & |
| 2995 N == NumValuedInsts |
| 2996 </pre> |
| 2997 <p><strong>Updates</strong>:</p> |
| 2998 <pre class="prettyprint"> |
| 2999 ++NumValuedInsts; |
| 3000 TypeOf(%vN) = T |
| 3001 </pre> |
| 3002 <p><strong>Examples</strong>:</p> |
| 3003 <pre class="prettyprint"> |
| 3004 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 3005 | | // BlockID = 12 |
| 3006 104:0| 3: <1, 1> | blocks 1; |
| 3007 | | %b0: |
| 3008 106:4| 3: <2, 2, 1, 2> | %v0 = mul i32 %p0, %p1; |
| 3009 110:4| 3: <2, 1, 3, 2> | %v1 = mul i32 %v0, %p0; |
| 3010 114:4| 3: <10, 1> | ret i32 %v1; |
| 3011 117:0| 0: <65534> | } |
| 3012 </pre> |
| 3013 <h3 id="signed-integer-divide">Signed Integer Divide</h3> |
| 3014 <p>The signed integer divide instruction returns the quotient of its two argumen
ts. |
| 3015 Both arguments and the result must be of the same type. That type must be |
| 3016 integer, or an integer vector type.</p> |
| 3017 <p><strong>Syntax</strong>:</p> |
| 3018 <pre class="prettyprint"> |
| 3019 %vN = sdiv T V1, V2; <A> |
| 3020 </pre> |
| 3021 <p><strong>Record</strong>:</p> |
| 3022 <pre class="prettyprint"> |
| 3023 AA: <2, VV1, VV2, 4> |
| 3024 </pre> |
| 3025 <p><strong>Semantics</strong>:</p> |
| 3026 <p>The signed integer divide instruction returns the quotient of its two |
| 3027 arguments. Arguments <code>V1</code> and <code>V2</code>, and the result <code>%
vN</code>, must be of type |
| 3028 <code>T</code>. <code>T</code> must be a integer type, or an integer vector type
. <code>N</code> is defined |
| 3029 by the record position, defining the corresponding value generated by the |
| 3030 instruction.</p> |
| 3031 <p>Signed values are assumed. Note that signed and unsigned integer division ar
e |
| 3032 distinct operations. For unsigned integer division use the unsigned integer |
| 3033 divide instruction (udiv).</p> |
| 3034 <p>In the signed integer divide instruction, integer type <code>i1</code> (and a
vector on |
| 3035 integer type <code>i1</code>) is disallowed. Integer division by zero is guarant
eed to |
| 3036 trap.</p> |
| 3037 <p>Note that overflow can happen with this instruction when dividing the maximum |
| 3038 negative integer by <code>-1</code>. The behavior for this case is currently und
efined.</p> |
| 3039 <p><strong>Constraints</strong>:</p> |
| 3040 <pre class="prettyprint"> |
| 3041 AA == AbbrevIndex(A) & |
| 3042 VV1 == RelativeIndex(V1) & |
| 3043 VV2 == RelativeIndex(V2) & |
| 3044 T == TypeOf(V1) == TypeOf(V2) & |
| 3045 IsInteger(UnderlyingType(T)) & |
| 3046 UnderlyingType(T) != i1 & |
| 3047 N == NumValuedInsts |
| 3048 </pre> |
| 3049 <p><strong>Updates</strong>:</p> |
| 3050 <pre class="prettyprint"> |
| 3051 ++NumValuedInsts; |
| 3052 TypeOf(%vN) = T |
| 3053 </pre> |
| 3054 <p><strong>Examples</strong>:</p> |
| 3055 <pre class="prettyprint"> |
| 3056 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 3057 | | // BlockID = 12 |
| 3058 104:0| 3: <1, 1> | blocks 1; |
| 3059 | | %b0: |
| 3060 106:4| 3: <2, 2, 1, 4> | %v0 = sdiv i32 %p0, %p1; |
| 3061 110:4| 3: <2, 1, 2, 4> | %v1 = sdiv i32 %v0, %p1; |
| 3062 114:4| 3: <10, 1> | ret i32 %v1; |
| 3063 117:0| 0: <65534> | } |
| 3064 </pre> |
| 3065 <h3 id="unsigned-integer-divide">Unsigned Integer Divide</h3> |
| 3066 <p>The unsigned integer divide instruction returns the quotient of its two |
| 3067 arguments. Both the arguments and the result must be of the same type. That type |
| 3068 must be integer, or an integer vector type.</p> |
| 3069 <p><strong>Syntax</strong>:</p> |
| 3070 <pre class="prettyprint"> |
| 3071 %vN = udiv T V1, V2; <a> |
| 3072 </pre> |
| 3073 <p><strong>Record</strong>:</p> |
| 3074 <pre class="prettyprint"> |
| 3075 AA: <2, A1, A2, 3> |
| 3076 </pre> |
| 3077 <p><strong>Semantics</strong>:</p> |
| 3078 <p>The unsigned integer divide instruction returns the quotient of its two |
| 3079 arguments. Arguments <code>V1</code> and <code>V2</code>, and the result <code>%
vN</code>, must be of type |
| 3080 <code>T</code>. <code>T</code> must be an integer type, or an integer vector typ
e. <code>N</code> is |
| 3081 defined by the record position, defining the corresponding value generated by |
| 3082 the instruction.</p> |
| 3083 <p>Unsigned integer values are assumed. Note that signed and unsigned integer |
| 3084 division are distinct operations. For signed integer division use the signed |
| 3085 integer divide instruction (sdiv).</p> |
| 3086 <p>In the unsigned integer divide instruction, integer type <code>i1</code> (and
a vector on |
| 3087 integer type <code>i1</code>) is disallowed. Division by zero is guaranteed to t
rap.</p> |
| 3088 <p><strong>Constraints</strong>:</p> |
| 3089 <pre class="prettyprint"> |
| 3090 AA == AbbrevIndex(A) & |
| 3091 VV1 == RelativeIndex(V1) & |
| 3092 VV2 == RelativeIndex(V2) & |
| 3093 T == TypeOf(V1) == TypeOf(V2) & |
| 3094 IsInteger(UnderlyingType(T)) & |
| 3095 UnderlyingType(T) != i1 & |
| 3096 N == NumValuedInsts |
| 3097 </pre> |
| 3098 <p><strong>Updates</strong>:</p> |
| 3099 <pre class="prettyprint"> |
| 3100 ++NumValuedInsts; |
| 3101 TypeOf(%vN) = T |
| 3102 </pre> |
| 3103 <p><strong>Examples</strong>:</p> |
| 3104 <pre class="prettyprint"> |
| 3105 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 3106 | | // BlockID = 12 |
| 3107 104:0| 3: <1, 1> | blocks 1; |
| 3108 | | %b0: |
| 3109 106:4| 3: <2, 2, 1, 3> | %v0 = udiv i32 %p0, %p1; |
| 3110 110:4| 3: <2, 1, 2, 3> | %v1 = udiv i32 %v0, %p1; |
| 3111 114:4| 3: <10, 1> | ret i32 %v1; |
| 3112 117:0| 0: <65534> | } |
| 3113 </pre> |
| 3114 <h3 id="signed-integer-remainder">Signed Integer Remainder</h3> |
| 3115 <p>The signed integer remainder instruction returns the remainder of the quotien
t |
| 3116 of its two arguments. Both arguments and the result must be of the same |
| 3117 type. That type must be integer, or an integer based vector type.</p> |
| 3118 <p><strong>Syntax</strong>:</p> |
| 3119 <pre class="prettyprint"> |
| 3120 %vN = srem T V1, V2; <A> |
| 3121 </pre> |
| 3122 <p><strong>Record</strong>:</p> |
| 3123 <pre class="prettyprint"> |
| 3124 AA: <2, VV1, VV2, 6> |
| 3125 </pre> |
| 3126 <p><strong>Semantics</strong>:</p> |
| 3127 <p>The signed integer remainder instruction returns the remainder of the quotien
t |
| 3128 of its two arguments. Arguments <code>V1</code> and <code>V2</code>, and the res
ult <code>%vN</code>, must |
| 3129 be of type <code>T</code>. <code>T</code> must be a integer type, or an integer
vector type. <code>N</code> |
| 3130 is defined by the record position, defining the corresponding value generated by |
| 3131 the instruction.</p> |
| 3132 <p>Signed values are assumed. Note that signed and unsigned integer division ar
e |
| 3133 distinct operations. For unsigned integer division use the unsigned integer |
| 3134 remainder instruction (urem).</p> |
| 3135 <p>In the signed integer remainder instruction, integer type <code>i1</code> (an
d a vector on |
| 3136 integer type <code>i1</code>) is disallowed. Division by zero is guaranteed to
trap.</p> |
| 3137 <p>Note that overflow can happen with this instruction when dividing the maximum |
| 3138 negative integer by <code>-1</code>. The behavior for this case is currently und
efined.</p> |
| 3139 <p><strong>Constraints</strong>:</p> |
| 3140 <pre class="prettyprint"> |
| 3141 AA == AbbrevIndex(A) & |
| 3142 VV1 == RelativeIndex(V1) & |
| 3143 VV2 == RelativeIndex(V2) & |
| 3144 T == TypeOf(V1) == TypeOf(V2) & |
| 3145 IsInteger(UnderlyingType(T)) & |
| 3146 UnderlyingType(T) != i1 & |
| 3147 N == NumValuedInsts |
| 3148 </pre> |
| 3149 <p><strong>Updates</strong>:</p> |
| 3150 <pre class="prettyprint"> |
| 3151 ++NumValuedInsts; |
| 3152 TypeOf(%vN) = T |
| 3153 </pre> |
| 3154 <p><strong>Examples</strong>:</p> |
| 3155 <pre class="prettyprint"> |
| 3156 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 3157 | | // BlockID = 12 |
| 3158 104:0| 3: <1, 1> | blocks 1; |
| 3159 | | %b0: |
| 3160 106:4| 3: <2, 2, 1, 6> | %v0 = srem i32 %p0, %p1; |
| 3161 110:4| 3: <2, 1, 2, 6> | %v1 = srem i32 %v0, %p1; |
| 3162 114:4| 3: <10, 1> | ret i32 %v1; |
| 3163 117:0| 0: <65534> | } |
| 3164 </pre> |
| 3165 <h3 id="unsigned-integer-remainder-instruction">Unsigned Integer Remainder Instr
uction</h3> |
| 3166 <p>The unsigned integer remainder instruction returns the remainder of the quoti
ent |
| 3167 of its two arguments. Both the arguments and the result must be of the same |
| 3168 type. The type must be integer, or an integer vector type.</p> |
| 3169 <p><strong>Syntax</strong>:</p> |
| 3170 <pre class="prettyprint"> |
| 3171 %vN = urem T V1, V2; <A> |
| 3172 </pre> |
| 3173 <p><strong>Record</strong>:</p> |
| 3174 <pre class="prettyprint"> |
| 3175 AA: <2, A1, A2, 5> |
| 3176 </pre> |
| 3177 <p><strong>Semantics</strong>:</p> |
| 3178 <p>The unsigned integer remainder instruction returns the remainder of the quoti
ent |
| 3179 of its two arguments. Arguments <code>V1</code> and <code>V2</code>, and the res
ult <code>%vN</code>, must |
| 3180 be of type <code>T</code>. <code>T</code> must be an integer type, or an integer
vector type. |
| 3181 <code>N</code> is defined by the record position, defining the corresponding val
ue |
| 3182 generated by the instruction.</p> |
| 3183 <p>Unsigned values are assumed. Note that signed and unsigned integer division a
re |
| 3184 distinct operations. For signed integer division use the remainder instruction |
| 3185 (srem).</p> |
| 3186 <p>In the unsigned integer remainder instruction, integer type <code>i1</code> (
and a vector on |
| 3187 integer type <code>i1</code>) is disallowed. Division by zero is guaranteed to
trap.</p> |
| 3188 <p><strong>Constraints</strong>:</p> |
| 3189 <pre class="prettyprint"> |
| 3190 AA == AbbrevIndex(A) & |
| 3191 VV1 == RelativeIndex(V1) & |
| 3192 VV2 == RelativeIndex(V2) & |
| 3193 T == TypeOf(V1) == TypeOf(V2) & |
| 3194 IsInteger(UnderlyingType(T)) & |
| 3195 UnderlyingType(T) != i1 & |
| 3196 N == NumValuedInsts |
| 3197 </pre> |
| 3198 <p><strong>Updates</strong>:</p> |
| 3199 <pre class="prettyprint"> |
| 3200 ++NumValuedInsts; |
| 3201 TypeOf(%vN) = T |
| 3202 </pre> |
| 3203 <p><strong>Examples</strong>:</p> |
| 3204 <pre class="prettyprint"> |
| 3205 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 3206 | | // BlockID = 12 |
| 3207 104:0| 3: <1, 1> | blocks 1; |
| 3208 | | %b0: |
| 3209 106:4| 3: <2, 2, 1, 5> | %v0 = urem i32 %p0, %p1; |
| 3210 110:4| 3: <2, 1, 2, 5> | %v1 = urem i32 %v0, %p1; |
| 3211 114:4| 3: <10, 1> | ret i32 %v1; |
| 3212 117:0| 0: <65534> | } |
| 3213 </pre> |
| 3214 <h3 id="shift-left">Shift Left</h3> |
| 3215 <p>The (integer) shift left instruction returns the first operand, shifted to th
e |
| 3216 left a specified number of bits with zero fill. The shifted value must be |
| 3217 integer, or an integer vector type.</p> |
| 3218 <p><strong>Syntax</strong>:</p> |
| 3219 <pre class="prettyprint"> |
| 3220 %vN = shl T V1, V2; <A> |
| 3221 </pre> |
| 3222 <p><strong>Record</strong>:</p> |
| 3223 <pre class="prettyprint"> |
| 3224 AA: <2, VV1, VV2, 7> |
| 3225 </pre> |
| 3226 <p><strong>Semantics</strong>:</p> |
| 3227 <p>This instruction performs a shift left operation. Arguments <code>V1</code> a
nd <code>V2</code> |
| 3228 and the result <code>%vN</code> must be of type <code>T</code>. <code>T</code> m
ust be an integer, or a |
| 3229 vector of integers. <code>N</code> is defined by the record position, defining t
he |
| 3230 corresponding value generated by the instruction.</p> |
| 3231 <p><code>V2</code> is assumed to be unsigned. The least significant bits of the
result will |
| 3232 be filled with zero bits after the shift. If <code>V2</code> is (statically or |
| 3233 dynamically) negative or equal to or larger than the number of bits in |
| 3234 <code>V1</code>, the result is undefined. If the arguments are vectors, each vec
tor |
| 3235 element of <code>V1</code> is shifted by the corresponding shift amount in <code
>V2</code>.</p> |
| 3236 <p>In the shift left instruction, integer type <code>i1</code> (and a vector on
integer type |
| 3237 <code>i1</code>) is disallowed.</p> |
| 3238 <p><strong>Constraints</strong>:</p> |
| 3239 <pre class="prettyprint"> |
| 3240 AA == AbbrevIndex(A) & |
| 3241 VV1 == RelativeIndex(V1) & |
| 3242 VV2 == RelativeIndex(V2) & |
| 3243 T == TypeOf(V1) == TypeOf(V2) & |
| 3244 IsInteger(UnderlyingType(T)) & |
| 3245 UnderlyingType(T) != i1 & |
| 3246 N == NumValuedInsts |
| 3247 </pre> |
| 3248 <p><strong>Updates</strong>:</p> |
| 3249 <pre class="prettyprint"> |
| 3250 ++NumValuedInsts; |
| 3251 TypeOf(%vN) = T |
| 3252 </pre> |
| 3253 <p><strong>Examples</strong>:</p> |
| 3254 <pre class="prettyprint"> |
| 3255 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 3256 | | // BlockID = 12 |
| 3257 104:0| 3: <1, 1> | blocks 1; |
| 3258 | | %b0: |
| 3259 106:4| 3: <2, 2, 1, 7> | %v0 = shl i32 %p0, %p1; |
| 3260 110:4| 3: <2, 1, 2, 7> | %v1 = shl i32 %v0, %p1; |
| 3261 114:4| 3: <10, 1> | ret i32 %v1; |
| 3262 117:0| 0: <65534> | } |
| 3263 </pre> |
| 3264 <h3 id="logical-shift-right">Logical Shift Right</h3> |
| 3265 <p>The logical shift right instruction returns the first operand, shifted to the |
| 3266 right a specified number of bits with zero fill.</p> |
| 3267 <p><strong>Syntax</strong>:</p> |
| 3268 <pre class="prettyprint"> |
| 3269 %vN = lshr T V1, V2; <A> |
| 3270 </pre> |
| 3271 <p><strong>Record</strong>:</p> |
| 3272 <pre class="prettyprint"> |
| 3273 AA: <2, VV1, VV2, 8> |
| 3274 </pre> |
| 3275 <p><strong>Semantics</strong>:</p> |
| 3276 <p>This instruction performs a logical shift right operation. Arguments <code>V1
</code> and |
| 3277 <code>V2</code> and the result <code>%vN</code> must be of type <code>T</code>.
<code>T</code> must be an integer, |
| 3278 or a vector of integers. <code>N</code> is defined by the record position, defin
ing the |
| 3279 corresponding value generated by the instruction.</p> |
| 3280 <p><code>V2</code> is assumed to be unsigned. The most significant bits of the r
esult will be |
| 3281 filled with zero bits after the shift. If <code>V2</code> is (statically or dyna
mically) |
| 3282 negative or equal to or larger than the number of bits in <code>V1</code>, the r
esult is |
| 3283 undefined. If the arguments are vectors, each vector element of <code>V1</code>
is shifted |
| 3284 by the corresponding shift amount in <code>V2</code>.</p> |
| 3285 <p>In the logical shift right instruction, integer type <code>i1</code> (and a v
ector on |
| 3286 integer type <code>i1</code>) is disallowed.</p> |
| 3287 <p><strong>Constraints</strong>:</p> |
| 3288 <pre class="prettyprint"> |
| 3289 AA == AbbrevIndex(A) & |
| 3290 VV1 == RelativeIndex(V1) & |
| 3291 VV2 == RelativeIndex(V2) & |
| 3292 T == TypeOf(V1) == TypeOf(V2) & |
| 3293 IsInteger(UnderlyingType(T)) & |
| 3294 UnderlyingType(T) != i1 & |
| 3295 N == NumValuedInsts |
| 3296 </pre> |
| 3297 <p><strong>Updates</strong>:</p> |
| 3298 <pre class="prettyprint"> |
| 3299 ++NumValuedInsts; |
| 3300 TypeOf(%vN) = T |
| 3301 </pre> |
| 3302 <p><strong>Examples</strong>:</p> |
| 3303 <pre class="prettyprint"> |
| 3304 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 3305 | | // BlockID = 12 |
| 3306 104:0| 3: <1, 1> | blocks 1; |
| 3307 | | %b0: |
| 3308 106:4| 3: <2, 2, 1, 8> | %v0 = lshr i32 %p0, %p1; |
| 3309 110:4| 3: <2, 1, 2, 8> | %v1 = lshr i32 %v0, %p1; |
| 3310 114:4| 3: <10, 1> | ret i32 %v1; |
| 3311 117:0| 0: <65534> | } |
| 3312 </pre> |
| 3313 <h3 id="arithmetic-shift-right">Arithmetic Shift Right</h3> |
| 3314 <p>The arithmetic shift right instruction returns the first operand, shifted to
the |
| 3315 right a specified number of bits with sign extension.</p> |
| 3316 <p><strong>Syntax</strong>:</p> |
| 3317 <pre class="prettyprint"> |
| 3318 %vN = ashr T V1, V2; <A> |
| 3319 </pre> |
| 3320 <p><strong>Record</strong>:</p> |
| 3321 <pre class="prettyprint"> |
| 3322 AA: <2, VV1, VVA2, 9> |
| 3323 </pre> |
| 3324 <p><strong>Semantics</strong>:</p> |
| 3325 <p>This instruction performs an arithmetic shift right operation. Arguments <cod
e>V1</code> |
| 3326 and <code>V2</code> and and the result <code>%vN</code> must be of type <code>T<
/code>. <code>T</code> must be an |
| 3327 integer, or a vector of integers. <code>N</code> is defined by the record positi
on, |
| 3328 defining the corresponding value generated by the instruction.</p> |
| 3329 <p><code>V2</code> is assumed to be unsigned. The most significant bits of the r
esult will be |
| 3330 filled with the sign bit of <code>V1</code>. If <code>V2</code> is (statically o
r dynamically) |
| 3331 negative or equal to or larger than the number of bits in <code>V1</code>, the r
esult is |
| 3332 undefined. If the arguments are vectors, each vector element of <code>V1</code>
is shifted |
| 3333 by the corresponding shift amount in <code>V2</code>.</p> |
| 3334 <p>In the arithmetic shift right instruction, integer type <code>i1</code> (and
a vector on |
| 3335 integrl type <code>i1</code>) is disallowed.</p> |
| 3336 <p><strong>Constraints</strong>:</p> |
| 3337 <pre class="prettyprint"> |
| 3338 AA == AbbrevIndex(A) & |
| 3339 VV1 == RelativeIndex(V1) & |
| 3340 VV2 == RelativeIndex(V2) & |
| 3341 T == TypeOf(V1) == TypeOf(V2) & |
| 3342 IsInteger(UnderlyingType(T)) & |
| 3343 UnderlyingType(T) != i1 & |
| 3344 N == NumValuedInsts |
| 3345 </pre> |
| 3346 <p><strong>Updates</strong>:</p> |
| 3347 <pre class="prettyprint"> |
| 3348 ++NumValuedInsts; |
| 3349 TypeOf(%vN) = T |
| 3350 </pre> |
| 3351 <p><strong>Examples</strong>:</p> |
| 3352 <pre class="prettyprint"> |
| 3353 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 3354 | | // BlockID = 12 |
| 3355 104:0| 3: <1, 1> | blocks 1; |
| 3356 | | %b0: |
| 3357 106:4| 3: <2, 2, 1, 9> | %v0 = ashr i32 %p0, %p1; |
| 3358 110:4| 3: <2, 1, 2, 9> | %v1 = ashr i32 %v0, %p1; |
| 3359 114:4| 3: <10, 1> | ret i32 %v1; |
| 3360 117:0| 0: <65534> | } |
| 3361 </pre> |
| 3362 <h3 id="logical-and">Logical And</h3> |
| 3363 <p>The <em>and</em> instruction returns the bitwise logical and of its two opera
nds.</p> |
| 3364 <p><strong>Syntax</strong>:</p> |
| 3365 <pre class="prettyprint"> |
| 3366 %vN = and T V1, V2; <A> |
| 3367 </pre> |
| 3368 <p><strong>Record</strong>:</p> |
| 3369 <pre class="prettyprint"> |
| 3370 AA: <2, VV1, VV2, 10> |
| 3371 </pre> |
| 3372 <p><strong>Semantics</strong>:</p> |
| 3373 <p>This instruction performs a bitwise logical and of its arguments. Arguments |
| 3374 <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 an |
| 3375 integer, or a vector of integers. <code>N</code> is defined by the record positi
on, |
| 3376 defining the corresponding value generated by the instruction. <code>A</code> i
s the |
| 3377 (optional) abbreviation associated with the corresponding record.</p> |
| 3378 <p>The truth table used for the <em>and</em> instruction is:</p> |
| 3379 <table border="1" class="docutils"> |
| 3380 <colgroup> |
| 3381 </colgroup> |
| 3382 <thead valign="bottom"> |
| 3383 <tr class="row-odd"><th class="head">Arg 1</th> |
| 3384 <th class="head">Arg 2</th> |
| 3385 <th class="head">Result</th> |
| 3386 </tr> |
| 3387 </thead> |
| 3388 <tbody valign="top"> |
| 3389 <tr class="row-even"><td>0</td> |
| 3390 <td>0</td> |
| 3391 <td>0</td> |
| 3392 </tr> |
| 3393 <tr class="row-odd"><td>0</td> |
| 3394 <td>1</td> |
| 3395 <td>0</td> |
| 3396 </tr> |
| 3397 <tr class="row-even"><td>1</td> |
| 3398 <td>0</td> |
| 3399 <td>0</td> |
| 3400 </tr> |
| 3401 <tr class="row-odd"><td>1</td> |
| 3402 <td>1</td> |
| 3403 <td>1</td> |
| 3404 </tr> |
| 3405 </tbody> |
| 3406 </table> |
| 3407 <p><strong>Constraints</strong>:</p> |
| 3408 <pre class="prettyprint"> |
| 3409 AA == AbbrevIndex(A) & |
| 3410 VV1 == RelativeIndex(V1) & |
| 3411 VV2 == RelativeIndex(V2) & |
| 3412 T == TypeOf(V1) == TypeOf(V2) & |
| 3413 IsInteger(UnderlyingType(T))) & |
| 3414 N == NumValuedInsts |
| 3415 </pre> |
| 3416 <p><strong>Updates</strong>:</p> |
| 3417 <pre class="prettyprint"> |
| 3418 ++NumValuedInsts; |
| 3419 TypeOf(%vN) = T |
| 3420 </pre> |
| 3421 <p><strong>Examples</strong>:</p> |
| 3422 <pre class="prettyprint"> |
| 3423 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 3424 | | // BlockID = 12 |
| 3425 104:0| 3: <1, 1> | blocks 1; |
| 3426 | | %b0: |
| 3427 106:4| 3: <2, 2, 1, 10> | %v0 = and i32 %p0, %p1; |
| 3428 110:4| 3: <2, 1, 2, 10> | %v1 = and i32 %v0, %p1; |
| 3429 114:4| 3: <10, 1> | ret i32 %v1; |
| 3430 117:0| 0: <65534> | } |
| 3431 </pre> |
| 3432 <h3 id="logical-or">Logical Or</h3> |
| 3433 <p>The <em>or</em> instruction returns the bitwise logical inclusive or of its |
| 3434 two operands.</p> |
| 3435 <p><strong>Syntax</strong>:</p> |
| 3436 <pre class="prettyprint"> |
| 3437 %vN = or T V1, V2; <A> |
| 3438 </pre> |
| 3439 <p><strong>Record</strong>:</p> |
| 3440 <pre class="prettyprint"> |
| 3441 AA: <2, VV1, VV2, 11> |
| 3442 </pre> |
| 3443 <p><strong>Semantics</strong>:</p> |
| 3444 <p>This instruction performs a bitwise logical inclusive or of its arguments. |
| 3445 Arguments <code>V1</code> and <code>V2</code>, and the result <code>%vN</code> m
ust be of type <code>T</code>. <code>T</code> |
| 3446 must be an integer, or a vector of integers. <code>N</code> is defined by the re
cord |
| 3447 position, defining the corresponding value generated by the instruction.</p> |
| 3448 <p>The truth table used for the <em>or</em> instruction is:</p> |
| 3449 <table border="1" class="docutils"> |
| 3450 <colgroup> |
| 3451 </colgroup> |
| 3452 <thead valign="bottom"> |
| 3453 <tr class="row-odd"><th class="head">Arg 1</th> |
| 3454 <th class="head">Arg 2</th> |
| 3455 <th class="head">Result</th> |
| 3456 </tr> |
| 3457 </thead> |
| 3458 <tbody valign="top"> |
| 3459 <tr class="row-even"><td>0</td> |
| 3460 <td>0</td> |
| 3461 <td>0</td> |
| 3462 </tr> |
| 3463 <tr class="row-odd"><td>0</td> |
| 3464 <td>1</td> |
| 3465 <td>1</td> |
| 3466 </tr> |
| 3467 <tr class="row-even"><td>1</td> |
| 3468 <td>0</td> |
| 3469 <td>1</td> |
| 3470 </tr> |
| 3471 <tr class="row-odd"><td>1</td> |
| 3472 <td>1</td> |
| 3473 <td>1</td> |
| 3474 </tr> |
| 3475 </tbody> |
| 3476 </table> |
| 3477 <p><strong>Constraints</strong>:</p> |
| 3478 <pre class="prettyprint"> |
| 3479 AA == AbbrevIndex(A) & |
| 3480 VV1 == RelativeIndex(V1) & |
| 3481 VV2 == RelativeIndex(V2) & |
| 3482 T == TypeOf(V1) == TypeOf(V2) & |
| 3483 IsInteger(UnderlyingType(T))) & |
| 3484 N == NumValuedInsts |
| 3485 </pre> |
| 3486 <p><strong>Updates</strong>:</p> |
| 3487 <pre class="prettyprint"> |
| 3488 ++NumValuedInsts; |
| 3489 TypeOf(%vN) = T |
| 3490 </pre> |
| 3491 <p><strong>Examples</strong>:</p> |
| 3492 <pre class="prettyprint"> |
| 3493 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 3494 | | // BlockID = 12 |
| 3495 104:0| 3: <1, 1> | blocks 1; |
| 3496 | | %b0: |
| 3497 106:4| 3: <2, 2, 1, 11> | %v0 = or i32 %p0, %p1; |
| 3498 110:4| 3: <2, 1, 2, 11> | %v1 = or i32 %v0, %p1; |
| 3499 114:4| 3: <10, 1> | ret i32 %v1; |
| 3500 117:0| 0: <65534> | } |
| 3501 </pre> |
| 3502 <h3 id="logical-xor">Logical Xor</h3> |
| 3503 <p>The <em>xor</em> instruction returns the bitwise logical exclusive or of its |
| 3504 two operands.</p> |
| 3505 <p><strong>Syntax</strong>:</p> |
| 3506 <pre class="prettyprint"> |
| 3507 %vN = xor T V1, V2; <A> |
| 3508 </pre> |
| 3509 <p><strong>Record</strong>:</p> |
| 3510 <pre class="prettyprint"> |
| 3511 AA: <2, VV1, VV2, 12> |
| 3512 </pre> |
| 3513 <p><strong>Semantics</strong>:</p> |
| 3514 <p>This instruction performs a bitwise logical exclusive or of its arguments. |
| 3515 Arguments <code>V1</code> and <code>V2</code>, and the result <code>%vN</code> m
ust be of type <code>T</code>. <code>T</code> |
| 3516 must be an integer, or a vector of integers. <code>N</code> is defined by the re
cord |
| 3517 position, defining the corresponding value generated by the instruction.</p> |
| 3518 <p>The truth table used for the <em>or</em> instruction is:</p> |
| 3519 <table border="1" class="docutils"> |
| 3520 <colgroup> |
| 3521 </colgroup> |
| 3522 <thead valign="bottom"> |
| 3523 <tr class="row-odd"><th class="head">Arg 1</th> |
| 3524 <th class="head">Arg 2</th> |
| 3525 <th class="head">Result</th> |
| 3526 </tr> |
| 3527 </thead> |
| 3528 <tbody valign="top"> |
| 3529 <tr class="row-even"><td>0</td> |
| 3530 <td>0</td> |
| 3531 <td>0</td> |
| 3532 </tr> |
| 3533 <tr class="row-odd"><td>0</td> |
| 3534 <td>1</td> |
| 3535 <td>1</td> |
| 3536 </tr> |
| 3537 <tr class="row-even"><td>1</td> |
| 3538 <td>0</td> |
| 3539 <td>1</td> |
| 3540 </tr> |
| 3541 <tr class="row-odd"><td>1</td> |
| 3542 <td>1</td> |
| 3543 <td>0</td> |
| 3544 </tr> |
| 3545 </tbody> |
| 3546 </table> |
| 3547 <p><strong>Constraints</strong>:</p> |
| 3548 <pre class="prettyprint"> |
| 3549 AA == AbbrevIndex(A) & |
| 3550 A1 == RelativeIndex(V1) & |
| 3551 A2 == RelativeIndex(V2) & |
| 3552 T == TypeOf(V1) == TypeOf(V2) & |
| 3553 IsInteger(UnderlyingType(T))) & |
| 3554 N == NumValuedInsts |
| 3555 </pre> |
| 3556 <p><strong>Updates</strong>:</p> |
| 3557 <pre class="prettyprint"> |
| 3558 ++NumValuedInsts; |
| 3559 TypeOf(%vN) = T |
| 3560 </pre> |
| 3561 <p><strong>Examples</strong>:</p> |
| 3562 <pre class="prettyprint"> |
| 3563 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 3564 | | // BlockID = 12 |
| 3565 104:0| 3: <1, 1> | blocks 1; |
| 3566 | | %b0: |
| 3567 106:4| 3: <2, 2, 1, 12> | %v0 = xor i32 %p0, %p1; |
| 3568 110:4| 3: <2, 1, 2, 12> | %v1 = xor i32 %v0, %p1; |
| 3569 114:4| 3: <10, 1> | ret i32 %v1; |
| 3570 117:0| 0: <65534> | } |
| 3571 </pre> |
| 3572 <h2 id="floating-point-binary-instructions"><span id="link-for-floating-point-bi
nary-instructions"></span>Floating Point Binary Instructions</h2> |
| 3573 <p>Floating point binary instructions require two operands of the same type, |
| 3574 execute an operation on them, and produce a value. The value may represent |
| 3575 multiple values if the type is a vector type. The result value always has the |
| 3576 same type as its operands.</p> |
| 3577 <h3 id="floating-point-add">Floating Point Add</h3> |
| 3578 <p>The floating point add instruction returns the sum of its two arguments. Both |
| 3579 arguments and the result must be of the same type. That type must be a floating |
| 3580 point type, or a vector of a floating point type.</p> |
| 3581 <p><strong>Syntax</strong>:</p> |
| 3582 <pre class="prettyprint"> |
| 3583 %vN = fadd T V1, V2; <A> |
| 3584 </pre> |
| 3585 <p><strong>Record</strong>:</p> |
| 3586 <pre class="prettyprint"> |
| 3587 AA: <2, VV1, VV2, 0> |
| 3588 </pre> |
| 3589 <p><strong>Semantics</strong>:</p> |
| 3590 <p>The floating point add instruction returns the sum of its two arguments. |
| 3591 Arguments <code>V1</code> and <code>V2</code> and the result <code>%vN</code> mu
st be of type <code>T</code>. <code>T</code> |
| 3592 must be a floating point type, or a vector of a floating point type. <code>N</co
de> is |
| 3593 defined by the record position, defining the corresponding value generated by |
| 3594 the instruction.</p> |
| 3595 <p><strong>Constraints</strong>:</p> |
| 3596 <pre class="prettyprint"> |
| 3597 AA == AbbrevIndex(A) & |
| 3598 VV1 == RelativeIndex(V1) & |
| 3599 VV2 == RelativeIndex(V2) & |
| 3600 T == TypeOf(V1) == TypeOf(V2) & |
| 3601 IsFloat(UnderlyingType(T)) & |
| 3602 N == NumValuedInsts |
| 3603 </pre> |
| 3604 <p><strong>Updates</strong>:</p> |
| 3605 <pre class="prettyprint"> |
| 3606 ++NumValuedInsts; |
| 3607 TypeOf(%vN) = T |
| 3608 </pre> |
| 3609 <p><strong>Examples</strong>:</p> |
| 3610 <pre class="prettyprint"> |
| 3611 92:0| 1: <65535, 12, 2> | function |
| 3612 | | float @f0(float %p0, float %p1) { |
| 3613 | | // BlockID = 12 |
| 3614 100:0| 3: <1, 1> | blocks 1; |
| 3615 | | %b0: |
| 3616 102:4| 3: <2, 2, 1, 0> | %v0 = fadd float %p0, %p1; |
| 3617 106:4| 3: <2, 3, 1, 0> | %v1 = fadd float %p0, %v0; |
| 3618 110:4| 3: <10, 1> | ret float %v1; |
| 3619 113:0| 0: <65534> | } |
| 3620 </pre> |
| 3621 <h3 id="floating-point-subtract">Floating Point Subtract</h3> |
| 3622 <p>The floating point subtract instruction returns the difference of its two |
| 3623 arguments. Both arguments and the result must be of the same type. That type |
| 3624 must be a floating point type, or a vector of a floating point type.</p> |
| 3625 <p><strong>Syntax</strong>:</p> |
| 3626 <pre class="prettyprint"> |
| 3627 %vN = fsub T V1, V2; <a> |
| 3628 </pre> |
| 3629 <p><strong>Record</strong>:</p> |
| 3630 <pre class="prettyprint"> |
| 3631 AA: <2, VV1, VV2, 1> |
| 3632 </pre> |
| 3633 <p><strong>Semantics</strong>:</p> |
| 3634 <p>The floating point subtract instruction returns the difference of its two |
| 3635 arguments. Arguments <code>V1</code> and <code>V2</code>, and the result <code>%
vN</code> must be of type |
| 3636 <code>T</code>. <code>T</code> must be a floating point type, or a vector of a f
loating point |
| 3637 type. <code>N</code> is defined by the record position, defining the correspondi
ng value |
| 3638 generated by the instruction.</p> |
| 3639 <p><strong>Constraints</strong>:</p> |
| 3640 <pre class="prettyprint"> |
| 3641 AA == AbbrevIndex(A) & |
| 3642 VV1 == RelativeIndex(V1) & |
| 3643 VV2 == RelativeIndex(V2) & |
| 3644 T == TypeOf(V1) == TypeOf(V2) & |
| 3645 IsFloat(UnderlyingType(T)) & |
| 3646 N == NumValuedInsts |
| 3647 </pre> |
| 3648 <p><strong>Updates</strong>:</p> |
| 3649 <pre class="prettyprint"> |
| 3650 ++NumValuedInsts; |
| 3651 TypeOf(%vN) = T |
| 3652 </pre> |
| 3653 <p><strong>Examples</strong>:</p> |
| 3654 <pre class="prettyprint"> |
| 3655 92:0| 1: <65535, 12, 2> | function |
| 3656 | | float @f0(float %p0, float %p1) { |
| 3657 | | // BlockID = 12 |
| 3658 100:0| 3: <1, 1> | blocks 1; |
| 3659 | | %b0: |
| 3660 102:4| 3: <2, 2, 1, 1> | %v0 = fsub float %p0, %p1; |
| 3661 106:4| 3: <2, 3, 1, 1> | %v1 = fsub float %p0, %v0; |
| 3662 110:4| 3: <10, 1> | ret float %v1; |
| 3663 113:0| 0: <65534> | } |
| 3664 </pre> |
| 3665 <h3 id="floating-point-multiply">Floating Point Multiply</h3> |
| 3666 <p>The floating point multiply instruction returns the product of its two |
| 3667 arguments. Both arguments and the result must be of the same type. That type |
| 3668 must be a floating point type, or a vector of a floating point type.</p> |
| 3669 <p><strong>Syntax</strong>:</p> |
| 3670 <pre class="prettyprint"> |
| 3671 &vN = fmul T V1, V2; <A> |
| 3672 </pre> |
| 3673 <p><strong>Record</strong>:</p> |
| 3674 <pre class="prettyprint"> |
| 3675 AA: <2, VV1, VV2, 2> |
| 3676 </pre> |
| 3677 <p><strong>Semantics</strong>:</p> |
| 3678 <p>The floating point multiply instruction returns the product of its two |
| 3679 arguments. Arguments <code>V1</code> and <code>V2</code>, and the result <code>%
vN</code> must be of type |
| 3680 <code>T</code>. <code>T</code> must be a floating point type, or a vector of a
floating point |
| 3681 type. <code>N</code> is defined by the record position, defining the correspondi
ng value |
| 3682 generated by the instruction.</p> |
| 3683 <p><strong>Constraints</strong>:</p> |
| 3684 <pre class="prettyprint"> |
| 3685 AA == AbbrevIndex(A) & |
| 3686 VV1 == RelativeIndex(V1) & |
| 3687 VV2 == RelativeIndex(V2) & |
| 3688 T == TypeOf(V1) == TypeOf(V2) & |
| 3689 IsFloat(UnderlyingType(T)) & |
| 3690 N == NumValuedInsts |
| 3691 </pre> |
| 3692 <p><strong>Updates</strong>:</p> |
| 3693 <pre class="prettyprint"> |
| 3694 ++NumValuedInsts; |
| 3695 TypeOf(%vN) = T |
| 3696 </pre> |
| 3697 <p><strong>Examples</strong>:</p> |
| 3698 <pre class="prettyprint"> |
| 3699 92:0| 1: <65535, 12, 2> | function |
| 3700 | | float @f0(float %p0, float %p1) { |
| 3701 | | // BlockID = 12 |
| 3702 100:0| 3: <1, 1> | blocks 1; |
| 3703 | | %b0: |
| 3704 102:4| 3: <2, 2, 1, 2> | %v0 = fmul float %p0, %p1; |
| 3705 106:4| 3: <2, 3, 1, 2> | %v1 = fmul float %p0, %v0; |
| 3706 110:4| 3: <10, 1> | ret float %v1; |
| 3707 113:0| 0: <65534> | } |
| 3708 </pre> |
| 3709 <h3 id="floating-point-divide">Floating Point Divide</h3> |
| 3710 <p>The floating point divide instruction returns the quotient of its two |
| 3711 arguments. Both arguments and the result must be of the same type. That type |
| 3712 must be a floating point type, or a vector of a floating point type.</p> |
| 3713 <p><strong>Syntax</strong>:</p> |
| 3714 <pre class="prettyprint"> |
| 3715 %vN = fdiv T V1, V2; <A> |
| 3716 </pre> |
| 3717 <p><strong>Record</strong>:</p> |
| 3718 <pre class="prettyprint"> |
| 3719 AA: <2, V1, V2, 4> |
| 3720 </pre> |
| 3721 <p><strong>Semantics</strong>:</p> |
| 3722 <p>The floating point divide instruction returns the quotient of its two |
| 3723 arguments. Arguments <code>V1</code> and <code>V2</code>, and the result <code>%
vN</code> must be of type |
| 3724 <code>T</code>. <code>T</code> must be a floating point type, or a vector of a f
loating point |
| 3725 type. <code>N</code> is defined by the record position, defining the correspondi
ng value |
| 3726 generated by the instruction.</p> |
| 3727 <p><strong>Constraints</strong>:</p> |
| 3728 <pre class="prettyprint"> |
| 3729 AA == AbbrevIndex(A) & |
| 3730 VV1 == RelativeIndex(V1) & |
| 3731 VV22 == RelativeIndex(V2) & |
| 3732 T == TypeOf(V1) == TypeOf(V2) & |
| 3733 IsFloat(UnderlyingType(T)) & |
| 3734 N == NumValuedInsts |
| 3735 </pre> |
| 3736 <p><strong>Updates</strong>:</p> |
| 3737 <pre class="prettyprint"> |
| 3738 ++NumValuedInsts; |
| 3739 TypeOf(%vN) = T; |
| 3740 </pre> |
| 3741 <p><strong>Examples</strong>:</p> |
| 3742 <pre class="prettyprint"> |
| 3743 92:0| 1: <65535, 12, 2> | function |
| 3744 | | double |
| 3745 | | @f0(double %p0, double %p1) { |
| 3746 | | // BlockID = 12 |
| 3747 100:0| 3: <1, 1> | blocks 1; |
| 3748 | | %b0: |
| 3749 102:4| 3: <2, 2, 1, 4> | %v0 = fdiv double %p0, %p1; |
| 3750 106:4| 3: <2, 3, 1, 4> | %v1 = fdiv double %p0, %v0; |
| 3751 110:4| 3: <10, 1> | ret double %v1; |
| 3752 113:0| 0: <65534> | } |
| 3753 </pre> |
| 3754 <h3 id="floating-point-remainder">Floating Point Remainder</h3> |
| 3755 <p>The floating point remainder instruction returns the remainder of the quotien
t |
| 3756 of its two arguments. Both arguments and the result must be of the same |
| 3757 type. That type must be a floating point type, or a vector of a floating point |
| 3758 type.</p> |
| 3759 <p><strong>Syntax</strong>:</p> |
| 3760 <pre class="prettyprint"> |
| 3761 %vN = frem T V1, V2; <A> |
| 3762 </pre> |
| 3763 <p><strong>Record</strong>:</p> |
| 3764 <pre class="prettyprint"> |
| 3765 AA: <2, VV1, VV2, 6> |
| 3766 </pre> |
| 3767 <p><strong>Semantics</strong>:</p> |
| 3768 <p>The floating point remainder instruction returns the remainder of the quotien
t |
| 3769 of its two arguments. Arguments <code>V1</code> and <code>V2</code>, and the res
ult <code>%vN</code> must be of |
| 3770 type <code>T</code>. <code>T</code> must be a floating point type, or a vector o
f a floating point |
| 3771 type. <code>N</code> is defined by the record position, defining the correspondi
ng value |
| 3772 generated by the instruction.</p> |
| 3773 <p><strong>Constraints</strong>:</p> |
| 3774 <pre class="prettyprint"> |
| 3775 AA == AbbrevIndex(A) & |
| 3776 VV1 == RelativeIndex(V1) & |
| 3777 VV2 == RelativeIndex(V2) & |
| 3778 T == TypeOf(V1) == TypeOf(V2) & |
| 3779 IsFloat(UnderlyingType(T)) & |
| 3780 N == NumValuedInsts |
| 3781 </pre> |
| 3782 <p><strong>Updates</strong>:</p> |
| 3783 <pre class="prettyprint"> |
| 3784 ++NumValuedInsts; |
| 3785 TypeOf(%vN) = T |
| 3786 </pre> |
| 3787 <p><strong>Examples</strong>:</p> |
| 3788 <pre class="prettyprint"> |
| 3789 92:0| 1: <65535, 12, 2> | function |
| 3790 | | double |
| 3791 | | @f0(double %p0, double %p1) { |
| 3792 | | // BlockID = 12 |
| 3793 100:0| 3: <1, 1> | blocks 1; |
| 3794 | | %b0: |
| 3795 102:4| 3: <2, 2, 1, 6> | %v0 = frem double %p0, %p1; |
| 3796 106:4| 3: <2, 3, 1, 6> | %v1 = frem double %p0, %v0; |
| 3797 110:4| 3: <10, 1> | ret double %v1; |
| 3798 113:0| 0: <65534> | } |
| 3799 </pre> |
| 3800 <h2 id="memory-creation-and-access-instructions"><span id="link-for-memory-creat
ion-and-access-instructions"></span>Memory Creation and Access Instructions</h2> |
| 3801 <p>A key design point of SSA-based representation is how it represents |
| 3802 memory. In PNaCl bitcode files, no memory locations are in SSA |
| 3803 form. This makes things very simple.</p> |
| 3804 <h3 id="alloca-instruction"><span id="link-for-alloca-instruction"></span>Alloca
Instruction</h3> |
| 3805 <p>The <em>alloca</em> instruction allocates memory on the stack frame of the |
| 3806 currently executing function. This memory is automatically released |
| 3807 when the function returns to its caller.</p> |
| 3808 <p><strong>Syntax</strong>:</p> |
| 3809 <pre class="prettyprint"> |
| 3810 %vN = alloca i8, i32 S, align V; <A> |
| 3811 </pre> |
| 3812 <p><strong>Record</strong>:</p> |
| 3813 <pre class="prettyprint"> |
| 3814 AA: <19, SS, VV> |
| 3815 </pre> |
| 3816 <p><strong>Semantics</strong>:</p> |
| 3817 <p>The <em>alloca</em> instruction allocates memory on the stack frame of the cu
rrently |
| 3818 executing function. The resulting value is a pointer to the allocated memory |
| 3819 (i.e. of type i32). <code>S</code> is the number of bytes that are allocated on
the |
| 3820 stack. <code>S</code> must be of integer type i32. <code>V</code> is the alignme
nt of the generated |
| 3821 stack address.</p> |
| 3822 <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 |
| 3823 alignment</em></a> for a more detailed |
| 3824 discussion on how to define alignment.</p> |
| 3825 <p><strong>Constraints</strong>:</p> |
| 3826 <pre class="prettyprint"> |
| 3827 AA == AbbrevIndex(A) & |
| 3828 VV == Log2(V+1) & |
| 3829 SS == RelativeIndex(S) & |
| 3830 i32 == TypeOf(S) & |
| 3831 N == NumValuedInsts |
| 3832 </pre> |
| 3833 <p><strong>Updates</strong>:</p> |
| 3834 <pre class="prettyprint"> |
| 3835 ++NumValuedInsts; |
| 3836 TypeOf(%vN) = i32; |
| 3837 </pre> |
| 3838 <p><strong>Examples</strong>:</p> |
| 3839 <pre class="prettyprint"> |
| 3840 112:0| 1: <65535, 12, 2> | function void @f1() { |
| 3841 | | // BlockID = 12 |
| 3842 120:0| 3: <1, 1> | blocks 1; |
| 3843 122:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 3844 132:0| 3: <1, 0> | i32: |
| 3845 134:4| 3: <4, 4> | %c0 = i32 2; |
| 3846 137:0| 3: <4, 8> | %c1 = i32 4; |
| 3847 139:4| 3: <4, 16> | %c2 = i32 8; |
| 3848 142:0| 0: <65534> | } |
| 3849 | | %b0: |
| 3850 144:0| 3: <19, 3, 1> | %v0 = alloca i8, i32 %c0, align 1; |
| 3851 147:2| 3: <19, 3, 3> | %v1 = alloca i8, i32 %c1, align 4; |
| 3852 150:4| 3: <19, 3, 4> | %v2 = alloca i8, i32 %c2, align 8; |
| 3853 153:6| 3: <10> | ret void; |
| 3854 155:4| 0: <65534> | } |
| 3855 </pre> |
| 3856 <h3 id="load-instruction">Load Instruction</h3> |
| 3857 <p>The <em>load</em> instruction is used to read from memory.</p> |
| 3858 <p><strong>Syntax</strong>:</p> |
| 3859 <pre class="prettyprint"> |
| 3860 %vN = load T* P, align V; <A> |
| 3861 </pre> |
| 3862 <p><strong>Record</strong>:</p> |
| 3863 <pre class="prettyprint"> |
| 3864 AA: <20, PP, VV, TT> |
| 3865 </pre> |
| 3866 <p><strong>Semantics</strong>:</p> |
| 3867 <p>The load instruction is used to read from memory. <code>P</code> is the ident
ifier of the |
| 3868 memory address to read. The type of <code>P</code> must be an <code>i32</code>.
<code>T</code> is the type |
| 3869 of value to read. <code>V</code> is the alignment of the memory address.</p> |
| 3870 <p>Type <code>T</code> must be a vector, integer, or floating point type. Both <
code>float</code> and |
| 3871 <code>double</code> types are allowed for floating point types. All integer type
s except i1 |
| 3872 are allowed.</p> |
| 3873 <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 |
| 3874 alignment</em></a> for a more detailed |
| 3875 discussion on how to define alignment.</p> |
| 3876 <p><strong>Constraints</strong>:</p> |
| 3877 <pre class="prettyprint"> |
| 3878 AA == AbbrevIndex(A) & |
| 3879 i32 == TypeOf(P) & |
| 3880 PP == RelativeIndex(P) & |
| 3881 VV == Log2(V+1) & |
| 3882 %tTT == TypeID(T) & |
| 3883 N == NumValuedInsts |
| 3884 </pre> |
| 3885 <p><strong>Updates</strong>:</p> |
| 3886 <pre class="prettyprint"> |
| 3887 ++NumValuedInsts; |
| 3888 TypeOf(%vN) = T; |
| 3889 </pre> |
| 3890 <p><strong>Examples</strong>:</p> |
| 3891 <pre class="prettyprint"> |
| 3892 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 3893 48:0| 3: <1, 4> | count 4; |
| 3894 50:4| 3: <7, 32> | @t0 = i32; |
| 3895 53:6| 3: <2> | @t1 = void; |
| 3896 55:4| 3: <4> | @t2 = double; |
| 3897 57:2| 3: <21, 0, 1, 0> | @t3 = void (i32); |
| 3898 61:2| 0: <65534> | } |
| 3899 ... |
| 3900 96:0| 1: <65535, 12, 2> | function void @f0(i32 %p0) { |
| 3901 | | // BlockID = 12 |
| 3902 104:0| 3: <1, 1> | blocks 1; |
| 3903 | | %b0: |
| 3904 106:4| 3: <20, 1, 1, 0> | %v0 = load i32* %p0, align 1; |
| 3905 110:4| 3: <20, 1, 4, 2> | %v1 = load double* %v0, align 8; |
| 3906 114:4| 3: <10> | ret void; |
| 3907 116:2| 0: <65534> | } |
| 3908 </pre> |
| 3909 <h3 id="store-instruction">Store Instruction</h3> |
| 3910 <p>The <em>store</em> instruction is used to write to memory.</p> |
| 3911 <p><strong>Syntax</strong>:</p> |
| 3912 <pre class="prettyprint"> |
| 3913 store T S, T* P, align V; <A> |
| 3914 </pre> |
| 3915 <p><strong>Record</strong>:</p> |
| 3916 <pre class="prettyprint"> |
| 3917 AA: <24, PP, SS, VV> |
| 3918 </pre> |
| 3919 <p><strong>Semantics</strong>:</p> |
| 3920 <p>The store instruction is used to write to memory. <code>P</code> is the ident
ifier of the |
| 3921 memory address to write to. The type of <code>P</code> must be an i32 integer.
<code>T</code> is |
| 3922 the type of value to store. <code>S</code> is the value to store, and must be of
type |
| 3923 <code>T</code>. <code>V</code> is the alignment of the memory address. <code>A
</code> is the (optional) |
| 3924 abbreviation index associated with the record.</p> |
| 3925 <p>Type <code>T</code> must be an integer or floating point type. Both <code>flo
at</code> and |
| 3926 <code>double</code> types are allowed for floating point types. All integer type
s except |
| 3927 i1 are allowed.</p> |
| 3928 <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 |
| 3929 alignment</em></a> for a more detailed |
| 3930 discussion on how to define alignment.</p> |
| 3931 <p><strong>Constraints</strong>:</p> |
| 3932 <pre class="prettyprint"> |
| 3933 AA == AbbrevIndex(A) & |
| 3934 i32 == TypeOf(P) & |
| 3935 PP == RelativeIndex(P) & |
| 3936 VV == Log2(V+1) |
| 3937 </pre> |
| 3938 <p><strong>Examples</strong>:</p> |
| 3939 <pre class="prettyprint"> |
| 3940 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 3941 48:0| 3: <1, 4> | count 4; |
| 3942 50:4| 3: <7, 32> | @t0 = i32; |
| 3943 53:6| 3: <2> | @t1 = void; |
| 3944 55:4| 3: <4> | @t2 = double; |
| 3945 57:2| 3: <21, 0, 1, 0, 0, 0, 2>| @t3 = void (i32, i32, i32, dou
ble); |
| 3946 63:4| 0: <65534> | } |
| 3947 ... |
| 3948 96:0| 1: <65535, 12, 2> | function |
| 3949 | | void |
| 3950 | | @f0(i32 %p0, i32 %p1, i32 %p2, |
| 3951 | | double %p3) { |
| 3952 | | // BlockID = 12 |
| 3953 104:0| 3: <1, 1> | blocks 1; |
| 3954 | | %b0: |
| 3955 106:4| 3: <24, 4, 3, 1> | store i32 %p1, i32* %p0, align 1; |
| 3956 110:4| 3: <24, 2, 1, 4> | store double %p3, double* %p2, |
| 3957 | | align 8; |
| 3958 114:4| 3: <10> | ret void; |
| 3959 116:2| 0: <65534> | } |
| 3960 </pre> |
| 3961 <h2 id="conversion-instructions"><span id="link-for-conversion-instructions"></s
pan>Conversion Instructions</h2> |
| 3962 <p>Conversion instructions all take a single operand and a type. The value is |
| 3963 converted to the corresponding type.</p> |
| 3964 <h3 id="integer-truncating-instruction">Integer Truncating Instruction</h3> |
| 3965 <p>The integer truncating instruction takes a value to truncate, and a type |
| 3966 defining the truncated type. Both types must be integer types, or integer |
| 3967 vectors with the same number of elements. The bit size of the value must be |
| 3968 larger than the bit size of the destination type. Equal sized types are not |
| 3969 allowed.</p> |
| 3970 <p><strong>Syntax</strong>:</p> |
| 3971 <pre class="prettyprint"> |
| 3972 %vN = trunc T1 V to T2; <A> |
| 3973 </pre> |
| 3974 <p><strong>Record</strong>:</p> |
| 3975 <pre class="prettyprint"> |
| 3976 AA: <3, VV, TT2, 0> |
| 3977 </pre> |
| 3978 <p><strong>Semantics</strong>:</p> |
| 3979 <p>The integer truncating instruction takes a value <code>V</code>, and truncate
s to type |
| 3980 <code>T2</code>. Both <code>T1</code> and <code>T2</code> must be integer types,
or integer vectors with the |
| 3981 same number of elements. <code>T1</code> has to be wider than <code>T2</code>.
If the value doesn’t |
| 3982 fit in in <code>T2</code>, then the higher order bits are dropped.</p> |
| 3983 <p><strong>Constraints</strong>:</p> |
| 3984 <pre class="prettyprint"> |
| 3985 AA == AbbrevIndex(A) & |
| 3986 TypeOf(V) == T1 & |
| 3987 VV == RelativeIndex(V) & |
| 3988 %tTT2 == TypeID(T2) & |
| 3989 BitSizeOf(UnderlyingType(T1)) > BitSizeOf(UnderlyingType(T2)) & |
| 3990 UnderlyingCount(T1) == UnderlyingCount(T2) & |
| 3991 IsInteger(UnderlyingType(T1)) & |
| 3992 IsInteger(UnderlyingType(T2)) & |
| 3993 N == NumValuedInsts |
| 3994 </pre> |
| 3995 <p><strong>Updates</strong>:</p> |
| 3996 <pre class="prettyprint"> |
| 3997 ++NumValuedInsts; |
| 3998 TypeOf(%vN) = T2; |
| 3999 </pre> |
| 4000 <p><strong>Examples</strong>:</p> |
| 4001 <pre class="prettyprint"> |
| 4002 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4003 48:0| 3: <1, 5> | count 5; |
| 4004 50:4| 3: <7, 32> | @t0 = i32; |
| 4005 53:6| 3: <2> | @t1 = void; |
| 4006 55:4| 3: <7, 16> | @t2 = i16; |
| 4007 58:0| 3: <21, 0, 1, 0> | @t3 = void (i32); |
| 4008 62:0| 3: <7, 8> | @t4 = i8; |
| 4009 64:4| 0: <65534> | } |
| 4010 ... |
| 4011 100:0| 1: <65535, 12, 2> | function void @f0(i32 %p0) { |
| 4012 | | // BlockID = 12 |
| 4013 108:0| 3: <1, 1> | blocks 1; |
| 4014 | | %b0: |
| 4015 110:4| 3: <3, 1, 2, 0> | %v0 = trunc i32 %p0 to i16; |
| 4016 114:4| 3: <3, 1, 4, 0> | %v1 = trunc i16 %v0 to i8; |
| 4017 118:4| 3: <10> | ret void; |
| 4018 120:2| 0: <65534> | } |
| 4019 </pre> |
| 4020 <h3 id="floating-point-truncating-instruction">Floating Point Truncating Instruc
tion</h3> |
| 4021 <p>The floating point truncating instruction takes a value to truncate, and a ty
pe |
| 4022 defining the truncated type. Both types must be floating point types, or |
| 4023 floating point vectors with the same number of elements. The source must be |
| 4024 <code>double</code> while the destination is <code>float</code>. If the source
is a vector, the |
| 4025 destination must also be vector with the same size as the source.</p> |
| 4026 <p><strong>Syntax</strong>:</p> |
| 4027 <pre class="prettyprint"> |
| 4028 %vN = fptrunc T1 V to T2; <A> |
| 4029 </pre> |
| 4030 <p><strong>Record</strong>:</p> |
| 4031 <pre class="prettyprint"> |
| 4032 AA: <3, VV, TT2, 7> |
| 4033 </pre> |
| 4034 <p><strong>Semantics</strong></p> |
| 4035 <p>The floating point truncating instruction takes a value <code>V</code>, and t
runcates to |
| 4036 type <code>T2</code>. Both <code>T1</code> and <code>T2</code> must be floating
point types, or floating |
| 4037 point vectors with the same number of elements. <code>T1</code> must be defined
on |
| 4038 <code>double</code> while <code>T2</code> is defined on <code>float</code>. If
the value can’t fit within |
| 4039 the destination type <code>T2</code>, the results are undefined.</p> |
| 4040 <p><strong>Constraints</strong>:</p> |
| 4041 <pre class="prettyprint"> |
| 4042 TypeOf(V) == T1 & |
| 4043 double == UnderlyingType(T1) & |
| 4044 float == UnderlyingType(T2) & |
| 4045 VV == RelativeIndex(V) & |
| 4046 %tTT2 == TypeID(T2) & |
| 4047 BitSizeOf(UnderlyingType(T1)) > BitSizeOf(UnderlyingType(T2)) & |
| 4048 UnderlyingCount(T1) == UnderlyingCount(T2) & |
| 4049 IsFloat(UnderlyingType(T1)) & |
| 4050 IsFloat(UnderlyingType(T2)) & |
| 4051 N == NumValuedInsts |
| 4052 </pre> |
| 4053 <p><strong>Updates</strong>:</p> |
| 4054 <pre class="prettyprint"> |
| 4055 ++NumValuedInsts; |
| 4056 TypeOf(%vN) = T2; |
| 4057 </pre> |
| 4058 <p><strong>Examples</strong>:</p> |
| 4059 <pre class="prettyprint"> |
| 4060 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4061 48:0| 3: <1, 4> | count 4; |
| 4062 50:4| 3: <3> | @t0 = float; |
| 4063 52:2| 3: <4> | @t1 = double; |
| 4064 54:0| 3: <21, 0, 0, 1> | @t2 = float (double); |
| 4065 58:0| 3: <2> | @t3 = void; |
| 4066 59:6| 0: <65534> | } |
| 4067 ... |
| 4068 92:0| 1: <65535, 12, 2> | function float @f0(double %p0) { |
| 4069 | | // BlockID = 12 |
| 4070 100:0| 3: <1, 1> | blocks 1; |
| 4071 | | %b0: |
| 4072 102:4| 3: <3, 1, 0, 7> | %v0 = fptrunc double %p0 to float; |
| 4073 106:4| 3: <10, 1> | ret float %v0; |
| 4074 109:0| 0: <65534> | } |
| 4075 </pre> |
| 4076 <h3 id="zero-extending-instruction">Zero Extending Instruction</h3> |
| 4077 <p>The zero extending instruction takes a value to extend, and a type to extend
it |
| 4078 to. Both types must be integer types, or integer vectors with the same number |
| 4079 of elements. The bit size of the source type must be smaller than the bit size |
| 4080 of the destination type. Equal sized types are not allowed.</p> |
| 4081 <p><strong>Syntax</strong>:</p> |
| 4082 <pre class="prettyprint"> |
| 4083 %vN = zext T1 V to T2; <A> |
| 4084 </pre> |
| 4085 <p><strong>Record</strong>:</p> |
| 4086 <pre class="prettyprint"> |
| 4087 AA: <3, VV, TT2, 1> |
| 4088 </pre> |
| 4089 <p><strong>Semantics</strong>:</p> |
| 4090 <p>The zero extending instruction takes a value <code>V</code>, and expands it t
o type |
| 4091 <code>T2</code>. Both <code>T1</code> and <code>T2</code> must be integer types,
or integer vectors with the |
| 4092 same number of elements. <code>T2</code> must be wider than <code>T1</code>.</p> |
| 4093 <p>The instruction fills the high order bits of the value with zero bits until i
t |
| 4094 reaches the size of the destination type. When zero extending from i1, the |
| 4095 result will always be either 0 or 1.</p> |
| 4096 <p><strong>Constraints</strong>:</p> |
| 4097 <pre class="prettyprint"> |
| 4098 AA == AbbrevIndex(A) & |
| 4099 TypeOf(V) == T1 & |
| 4100 VV == RelativeIndex(V) & |
| 4101 %tTT2 == TypeID(T2) & |
| 4102 BitSizeOf(UnderlyingType(T1)) < BitSizeOf(UnderlyingType(T2)) & |
| 4103 UnderlyingCount(T1) == UnderlyingCount(T2) & |
| 4104 IsInteger(UnderlyingType(T1)) & |
| 4105 IsInteger(UnderlyingType(T2)) & |
| 4106 N == NumValuedInsts |
| 4107 </pre> |
| 4108 <p><strong>Updates</strong>:</p> |
| 4109 <pre class="prettyprint"> |
| 4110 ++NumValuedInsts; |
| 4111 TypeOf(%vN) = T2; |
| 4112 </pre> |
| 4113 <p><strong>Examples</strong>:</p> |
| 4114 <pre class="prettyprint"> |
| 4115 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4116 48:0| 3: <1, 5> | count 5; |
| 4117 50:4| 3: <7, 64> | @t0 = i64; |
| 4118 53:6| 3: <7, 32> | @t1 = i32; |
| 4119 57:0| 3: <21, 0, 0> | @t2 = i64 (); |
| 4120 60:2| 3: <7, 8> | @t3 = i8; |
| 4121 62:6| 3: <2> | @t4 = void; |
| 4122 64:4| 0: <65534> | } |
| 4123 ... |
| 4124 100:0| 1: <65535, 12, 2> | function i64 @f0() { // BlockID
= 12 |
| 4125 108:0| 3: <1, 1> | blocks 1; |
| 4126 110:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 4127 120:0| 3: <1, 3> | i8: |
| 4128 122:4| 3: <4, 2> | %c0 = i8 1; |
| 4129 125:0| 0: <65534> | } |
| 4130 | | %b0: |
| 4131 128:0| 3: <3, 1, 1, 1> | %v0 = zext i8 %c0 to i32; |
| 4132 132:0| 3: <3, 1, 0, 1> | %v1 = zext i32 %v0 to i64; |
| 4133 136:0| 3: <10, 1> | ret i64 %v1; |
| 4134 138:4| 0: <65534> | } |
| 4135 </pre> |
| 4136 <h3 id="sign-extending-instruction">Sign Extending Instruction</h3> |
| 4137 <p>The sign extending instruction takes a value to cast, and a type to extend it |
| 4138 to. Both types must be integer types, or integarl vectors with the same number |
| 4139 of elements. The bit size of the source type must be smaller than the bit size |
| 4140 of the destination type. Equal sized types are not allowed.</p> |
| 4141 <p><strong>Syntax</strong>:</p> |
| 4142 <pre class="prettyprint"> |
| 4143 %vN = sext T1 V to T2; <A> |
| 4144 </pre> |
| 4145 <p><strong>Record</strong>:</p> |
| 4146 <pre class="prettyprint"> |
| 4147 AA: <3, VV, TT2, 2> |
| 4148 </pre> |
| 4149 <p><strong>Semantics</strong>:</p> |
| 4150 <p>The sign extending instruction takes a value <code>V</code>, and expands it t
o type |
| 4151 <code>T2</code>. Both <code>T1</code> and <code>T2</code> must be integer types,
or integer vectors with the |
| 4152 same number of integers. <code>T2</code> has to be wider than <code>T1</code>.<
/p> |
| 4153 <p>When sign extending, the instruction fills the high order bits of the value w
ith |
| 4154 the (current) high order bit of the value. When sign extending from i1, the |
| 4155 extension always results in -1 or 0.</p> |
| 4156 <p><strong>Constraints</strong>:</p> |
| 4157 <pre class="prettyprint"> |
| 4158 AA == AbbrevIndex(A) & |
| 4159 TypeOf(V) == T1 & |
| 4160 VV == RelativeIndex(V) & |
| 4161 %tTT2 == TypeID(T2) & |
| 4162 BitSizeOf(UnderlyingType(T1)) < BitSizeOf(UnderlyingType(T2)) & |
| 4163 UnderlyingCount(T1) == UnderlyingCount(T2) & |
| 4164 IsInteger(UnderlyingType(T1)) & |
| 4165 IsInteger(UnderlyingType(T2)) & |
| 4166 N == NumValuedInsts |
| 4167 </pre> |
| 4168 <p><strong>Updates</strong>:</p> |
| 4169 <pre class="prettyprint"> |
| 4170 ++NumValuedInsts; |
| 4171 TypeOf(%vN) = T2; |
| 4172 </pre> |
| 4173 <p><strong>Examples</strong>:</p> |
| 4174 <pre class="prettyprint"> |
| 4175 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4176 48:0| 3: <1, 5> | count 5; |
| 4177 50:4| 3: <7, 64> | @t0 = i64; |
| 4178 53:6| 3: <7, 32> | @t1 = i32; |
| 4179 57:0| 3: <21, 0, 0> | @t2 = i64 (); |
| 4180 60:2| 3: <7, 8> | @t3 = i8; |
| 4181 62:6| 3: <2> | @t4 = void; |
| 4182 64:4| 0: <65534> | } |
| 4183 ... |
| 4184 100:0| 1: <65535, 12, 2> | function i64 @f0() { // BlockID
= 12 |
| 4185 108:0| 3: <1, 1> | blocks 1; |
| 4186 110:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 4187 120:0| 3: <1, 3> | i8: |
| 4188 122:4| 3: <4, 3> | %c0 = i8 -1; |
| 4189 125:0| 0: <65534> | } |
| 4190 | | %b0: |
| 4191 128:0| 3: <3, 1, 1, 2> | %v0 = sext i8 %c0 to i32; |
| 4192 132:0| 3: <3, 1, 0, 2> | %v1 = sext i32 %v0 to i64; |
| 4193 136:0| 3: <10, 1> | ret i64 %v1; |
| 4194 138:4| 0: <65534> | } |
| 4195 </pre> |
| 4196 <h3 id="floating-point-extending-instruction">Floating Point Extending Instructi
on</h3> |
| 4197 <p>The floating point extending instruction takes a value to extend, and a type
to |
| 4198 extend it to. Both types must either be floating point types, or vectors of |
| 4199 floating point types with the same number of elements. The source value must be |
| 4200 <code>float</code> while the destination is <code>double</code>. If the source
is a vector, the |
| 4201 destination must also be vector with the same size as the source.</p> |
| 4202 <p><strong>Syntax</strong>:</p> |
| 4203 <pre class="prettyprint"> |
| 4204 %vN = fpext T1 V to T2; <A> |
| 4205 </pre> |
| 4206 <p><strong>Record</strong>:</p> |
| 4207 <pre class="prettyprint"> |
| 4208 AA: <3, VV, TT2, 8> |
| 4209 </pre> |
| 4210 <p><strong>Semantics</strong>:</p> |
| 4211 <p>The floating point extending instruction converts floating point values. |
| 4212 <code>V</code> is the value to extend, and <code>T2</code> is the type to extend
it |
| 4213 to. Both <code>T1</code> and <code>T2</code> must be floating point types, or fl
oating point |
| 4214 vector types with the same number of floating point values. <code>T1</code> cont
ains |
| 4215 <code>float</code> while <code>T2</code> contains <code>double</code>.</p> |
| 4216 <p><strong>Constraints</strong>:</p> |
| 4217 <pre class="prettyprint"> |
| 4218 AA == AbbrevIndex(A) & |
| 4219 TypeOf(V) == T1 & |
| 4220 VV == RelativeIndex(V) & |
| 4221 %tTT2 == TypeID(T2) & |
| 4222 BitSizeOf(UnderlyingType(T1)) < BitSizeOf(UnderlyingType(T2)) & |
| 4223 UnderlyingCount(T1) == UnderlyingCount(T2) & |
| 4224 IsFloat(UnderlyingType(T1)) & |
| 4225 IsFloat(UnderlyingType(T2)) & |
| 4226 N == NumValuedInsts |
| 4227 </pre> |
| 4228 <p><strong>Updates</strong>:</p> |
| 4229 <pre class="prettyprint"> |
| 4230 ++NumValuedInsts; |
| 4231 TypeOf(%vN) = T2; |
| 4232 </pre> |
| 4233 <p><strong>Examples</strong>:</p> |
| 4234 <pre class="prettyprint"> |
| 4235 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4236 48:0| 3: <1, 4> | count 4; |
| 4237 50:4| 3: <4> | @t0 = double; |
| 4238 52:2| 3: <3> | @t1 = float; |
| 4239 54:0| 3: <21, 0, 0, 1> | @t2 = double (float); |
| 4240 58:0| 3: <2> | @t3 = void; |
| 4241 59:6| 0: <65534> | } |
| 4242 ... |
| 4243 92:0| 1: <65535, 12, 2> | function double @f0(float %p0) { |
| 4244 | | // BlockID = 12 |
| 4245 100:0| 3: <1, 1> | blocks 1; |
| 4246 | | %b0: |
| 4247 102:4| 3: <3, 1, 0, 8> | %v0 = fpext float %p0 to double; |
| 4248 106:4| 3: <10, 1> | ret double %v0; |
| 4249 109:0| 0: <65534> | } |
| 4250 </pre> |
| 4251 <h3 id="floating-point-to-unsigned-integer-instruction">Floating Point to Unsign
ed Integer Instruction</h3> |
| 4252 <p>The floating point to unsigned integer instruction converts floating point |
| 4253 values to unsigned integers.</p> |
| 4254 <p><strong>Syntax</strong>:</p> |
| 4255 <pre class="prettyprint"> |
| 4256 %vN = fptoui T1 V to T2; <A> |
| 4257 </pre> |
| 4258 <p><strong>Record</strong>:</p> |
| 4259 <pre class="prettyprint"> |
| 4260 AA: <3, VV, TT2, 3> |
| 4261 </pre> |
| 4262 <p><strong>Semantics</strong>:</p> |
| 4263 <p>The floating point to unsigned integer instruction converts floating point |
| 4264 value(s) in <code>V</code> to its unsigned integer equivalent of type <code>T2</
code>. <code>T1</code> must |
| 4265 be a floating point type, or a floating point vector type. <code>T2</code> must
be an |
| 4266 integer type, or a integer vector type. If either type is a vector type, they |
| 4267 both must have the same number of elements.</p> |
| 4268 <p><strong>Constraints</strong>:</p> |
| 4269 <pre class="prettyprint"> |
| 4270 AA == AbbrevIndex(A) & |
| 4271 TypeOf(V) == T1 & |
| 4272 VV == RelativeIndex(V) & |
| 4273 %tTT2 == TypeID(T2) & |
| 4274 UnderlyingCount(T1) == UnderlyingCount(T2) & |
| 4275 IsFloat(UnderlyingType(T1)) & |
| 4276 IsInteger(UnderlyingType(T2)) & |
| 4277 N == NumValuedInsts |
| 4278 </pre> |
| 4279 <p><strong>Updates</strong>:</p> |
| 4280 <pre class="prettyprint"> |
| 4281 ++NumValuedInsts; |
| 4282 TypeOf(%vN) = T2; |
| 4283 </pre> |
| 4284 <p><strong>Examples</strong>:</p> |
| 4285 <pre class="prettyprint"> |
| 4286 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4287 48:0| 3: <1, 6> | count 6; |
| 4288 50:4| 3: <3> | @t0 = float; |
| 4289 52:2| 3: <4> | @t1 = double; |
| 4290 54:0| 3: <2> | @t2 = void; |
| 4291 55:6| 3: <21, 0, 2, 0, 1> | @t3 = void (float, double); |
| 4292 60:4| 3: <7, 32> | @t4 = i32; |
| 4293 63:6| 3: <7, 16> | @t5 = i16; |
| 4294 66:2| 0: <65534> | } |
| 4295 ... |
| 4296 100:0| 1: <65535, 12, 2> | function |
| 4297 | | void @f0(float %p0, double %p1) { |
| 4298 | | // BlockID = 12 |
| 4299 108:0| 3: <1, 1> | blocks 1; |
| 4300 | | %b0: |
| 4301 110:4| 3: <3, 2, 4, 3> | %v0 = fptoui float %p0 to i32; |
| 4302 114:4| 3: <3, 2, 5, 3> | %v1 = fptoui double %p1 to i16; |
| 4303 118:4| 3: <10> | ret void; |
| 4304 120:2| 0: <65534> | } |
| 4305 </pre> |
| 4306 <h3 id="floating-point-to-signed-integer-instruction">Floating Point to Signed I
nteger Instruction</h3> |
| 4307 <p>The floating point to signed integer instruction converts floating point |
| 4308 values to signed integers.</p> |
| 4309 <p><strong>Syntax</strong>:</p> |
| 4310 <pre class="prettyprint"> |
| 4311 %vN = fptosi T1 V to T2; <A> |
| 4312 </pre> |
| 4313 <p><strong>Record</strong>:</p> |
| 4314 <pre class="prettyprint"> |
| 4315 AA: <3, VV, TT2, 4> |
| 4316 </pre> |
| 4317 <p><strong>Semantics</strong>:</p> |
| 4318 <p>The floating point to signed integer instruction converts floating point valu
e(s) |
| 4319 in <code>V</code> to its signed integer equivalent of type <code>T2</code>. <cod
e>T1</code> must be a |
| 4320 floating point type, or a floating point vector type. <code>T2</code> must be an
integer |
| 4321 type, or a integer vector type. If either type is a vector type, they both must |
| 4322 have the same number of elements.</p> |
| 4323 <p><strong>Constraints</strong>:</p> |
| 4324 <pre class="prettyprint"> |
| 4325 AA == AbbrevIndex(A) & |
| 4326 TypeOf(V) == T1 & |
| 4327 VV == RelativeIndex(V) & |
| 4328 %tTT2 = TypeID(T2) & |
| 4329 UnderlyingCount(T1) = UnderlyingCount(T2) & |
| 4330 IsFloat(UnderlyingType(T1)) & |
| 4331 IsInteger(UnderlyingType(T2)) & |
| 4332 N = NumValuedInsts |
| 4333 </pre> |
| 4334 <p><strong>Updates</strong>:</p> |
| 4335 <pre class="prettyprint"> |
| 4336 ++NumValuedInsts; |
| 4337 TypeOf(%vN) = T2; |
| 4338 </pre> |
| 4339 <p><strong>Examples</strong>:</p> |
| 4340 <pre class="prettyprint"> |
| 4341 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4342 48:0| 3: <1, 6> | count 6; |
| 4343 50:4| 3: <3> | @t0 = float; |
| 4344 52:2| 3: <4> | @t1 = double; |
| 4345 54:0| 3: <2> | @t2 = void; |
| 4346 55:6| 3: <21, 0, 2, 0, 1> | @t3 = void (float, double); |
| 4347 60:4| 3: <7, 8> | @t4 = i8; |
| 4348 63:0| 3: <7, 16> | @t5 = i16; |
| 4349 65:4| 0: <65534> | } |
| 4350 ... |
| 4351 100:0| 1: <65535, 12, 2> | function |
| 4352 | | void @f0(float %p0, double %p1) { |
| 4353 | | // BlockID = 12 |
| 4354 108:0| 3: <1, 1> | blocks 1; |
| 4355 | | %b0: |
| 4356 110:4| 3: <3, 2, 4, 4> | %v0 = fptosi float %p0 to i8; |
| 4357 114:4| 3: <3, 2, 5, 4> | %v1 = fptosi double %p1 to i16; |
| 4358 118:4| 3: <10> | ret void; |
| 4359 120:2| 0: <65534> | } |
| 4360 </pre> |
| 4361 <h3 id="unsigned-integer-to-floating-point-instruction">Unsigned Integer to Floa
ting Point Instruction</h3> |
| 4362 <p>The unsigned integer to floating point instruction converts unsigned integers
to |
| 4363 floating point values.</p> |
| 4364 <p><strong>Syntax</strong>:</p> |
| 4365 <pre class="prettyprint"> |
| 4366 %vN = uitofp T1 V to T2; <A> |
| 4367 </pre> |
| 4368 <p><strong>Record</strong>:</p> |
| 4369 <pre class="prettyprint"> |
| 4370 AA: <3, VV, TT2, 5> |
| 4371 </pre> |
| 4372 <p><strong>Semantics</strong>:</p> |
| 4373 <p>The unsigned integer to floating point instruction converts unsigned integer(
s) to |
| 4374 its floating point equivalent of type <code>T2</code>. <code>T1</code> must be a
n integer type, or |
| 4375 a integer vector type. <code>T2</code> must be a floating point type, or a float
ing point |
| 4376 vector type. If either type is a vector type, they both must have the |
| 4377 same number of elements.</p> |
| 4378 <p><strong>Constraints</strong>:</p> |
| 4379 <pre class="prettyprint"> |
| 4380 AA == AbbrevIndex(A) & |
| 4381 TypeOf(V) == T1 & |
| 4382 VV == RelativeIndex(V) & |
| 4383 %tTT2 = TypeID(T2) & |
| 4384 UnderlyingCount(T1) == UnderlyingCount(T2) & |
| 4385 IsInteger(UnderlyingType(T1)) & |
| 4386 IsFloat(UnderlyingType(T2)) & |
| 4387 N == NumValuedInsts |
| 4388 </pre> |
| 4389 <p><strong>Updates</strong>:</p> |
| 4390 <pre class="prettyprint"> |
| 4391 ++NumValuedInsts; |
| 4392 TypeOf(%vN) == T2; |
| 4393 </pre> |
| 4394 <p><strong>Examples</strong>:</p> |
| 4395 <pre class="prettyprint"> |
| 4396 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4397 48:0| 3: <1, 7> | count 7; |
| 4398 50:4| 3: <7, 32> | @t0 = i32; |
| 4399 53:6| 3: <7, 64> | @t1 = i64; |
| 4400 57:0| 3: <2> | @t2 = void; |
| 4401 58:6| 3: <3> | @t3 = float; |
| 4402 60:4| 3: <21, 0, 2, 0, 1> | @t4 = void (i32, i64); |
| 4403 65:2| 3: <7, 1> | @t5 = i1; |
| 4404 67:6| 3: <4> | @t6 = double; |
| 4405 69:4| 0: <65534> | } |
| 4406 ... |
| 4407 104:0| 1: <65535, 12, 2> | function void @f0(i32 %p0, i64 %
p1) { |
| 4408 | | // BlockID = 12 |
| 4409 112:0| 3: <1, 1> | blocks 1; |
| 4410 114:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 4411 124:0| 3: <1, 5> | i1: |
| 4412 126:4| 3: <4, 3> | %c0 = i1 1; |
| 4413 129:0| 0: <65534> | } |
| 4414 | | %b0: |
| 4415 132:0| 3: <3, 1, 6, 5> | %v0 = uitofp i1 %c0 to double; |
| 4416 136:0| 3: <3, 4, 3, 5> | %v1 = uitofp i32 %p0 to float; |
| 4417 140:0| 3: <3, 4, 3, 5> | %v2 = uitofp i64 %p1 to float; |
| 4418 144:0| 3: <10> | ret void; |
| 4419 145:6| 0: <65534> | } |
| 4420 </pre> |
| 4421 <h3 id="signed-integer-to-floating-point-instruction">Signed Integer to Floating
Point Instruction</h3> |
| 4422 <p>The signed integer to floating point instruction converts signed integers to |
| 4423 floating point values.</p> |
| 4424 <p><strong>Syntax</strong>:</p> |
| 4425 <pre class="prettyprint"> |
| 4426 %vN = sitofp T1 V to T2; <A> |
| 4427 </pre> |
| 4428 <p><strong>Record</strong>:</p> |
| 4429 <pre class="prettyprint"> |
| 4430 AA: <3, VV, TT2, 6> |
| 4431 </pre> |
| 4432 <p><strong>Semantics</strong>:</p> |
| 4433 <p>The signed integer to floating point instruction converts signed integer(s) t
o its |
| 4434 floating point equivalent of type <code>T2</code>. <code>T1</code> must be an in
teger type, or a |
| 4435 integer vector type. <code>T2</code> must be a floating point type, or a floatin
g point |
| 4436 vector type. If either type is a vector type, they both must have the |
| 4437 same number of elements.</p> |
| 4438 <p><strong>Constraints</strong>:</p> |
| 4439 <pre class="prettyprint"> |
| 4440 AA == AbbrevIndex(A) & |
| 4441 TypeOf(V) == T1 & |
| 4442 VV == RelativeIndex(V) & |
| 4443 %tTT2 = TypeID(T2) & |
| 4444 UnderlyingCount(T1) == UnderlyingCount(T2) & |
| 4445 IsInteger(UnderlyingType(T1)) & |
| 4446 IsFloat(UnderlyingType(T2)) & |
| 4447 N == NumValuedInsts |
| 4448 </pre> |
| 4449 <p><strong>Updates</strong>:</p> |
| 4450 <pre class="prettyprint"> |
| 4451 ++NumValuedInsts; |
| 4452 TypeOf(%vN) = T2; |
| 4453 </pre> |
| 4454 <p><strong>Examples</strong>:</p> |
| 4455 <pre class="prettyprint"> |
| 4456 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4457 48:0| 3: <1, 7> | count 7; |
| 4458 50:4| 3: <7, 32> | @t0 = i32; |
| 4459 53:6| 3: <7, 64> | @t1 = i64; |
| 4460 57:0| 3: <2> | @t2 = void; |
| 4461 58:6| 3: <3> | @t3 = float; |
| 4462 60:4| 3: <21, 0, 2, 0, 1> | @t4 = void (i32, i64); |
| 4463 65:2| 3: <7, 8> | @t5 = i8; |
| 4464 67:6| 3: <4> | @t6 = double; |
| 4465 69:4| 0: <65534> | } |
| 4466 ... |
| 4467 104:0| 1: <65535, 12, 2> | function void @f0(i32 %p0, i64 %
p1) { |
| 4468 | | // BlockID = 12 |
| 4469 112:0| 3: <1, 1> | blocks 1; |
| 4470 114:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 4471 124:0| 3: <1, 5> | i8: |
| 4472 126:4| 3: <4, 3> | %c0 = i8 -1; |
| 4473 129:0| 0: <65534> | } |
| 4474 | | %b0: |
| 4475 132:0| 3: <3, 1, 6, 6> | %v0 = sitofp i8 %c0 to double; |
| 4476 136:0| 3: <3, 4, 3, 6> | %v1 = sitofp i32 %p0 to float; |
| 4477 140:0| 3: <3, 4, 3, 6> | %v2 = sitofp i64 %p1 to float; |
| 4478 144:0| 3: <10> | ret void; |
| 4479 145:6| 0: <65534> | } |
| 4480 </pre> |
| 4481 <h3 id="bitcast-instruction">Bitcast Instruction</h3> |
| 4482 <p>The bitcast instruction converts the type of the value without changing the b
it |
| 4483 contents of the value. The bit size of the type of the value must be the same as |
| 4484 the bit size of the cast type.</p> |
| 4485 <p><strong>Syntax</strong>:</p> |
| 4486 <pre class="prettyprint"> |
| 4487 %vN = bitcast T1 V to T2; <A> |
| 4488 </pre> |
| 4489 <p><strong>Record</strong>:</p> |
| 4490 <pre class="prettyprint"> |
| 4491 AA: <3, VV, TT2, 11> |
| 4492 </pre> |
| 4493 <p><strong>Semantics</strong>:</p> |
| 4494 <p>The bitcast instruction converts the type of value <code>V</code> to type <co
de>T2</code>. <code>T1</code> |
| 4495 and <code>T2</code> must be primitive types or vectors, and define the same numb
er of |
| 4496 bits.</p> |
| 4497 <p><strong>Constraints</strong>:</p> |
| 4498 <pre class="prettyprint"> |
| 4499 AA == AbbrevIndex(A) & |
| 4500 TypeOf(V) == T1 & |
| 4501 VV = RelativeIndex(V) & |
| 4502 %tTT2 = TypeID(T2) & |
| 4503 BitSizeOf(T1) == BitSizeOf(T2) & |
| 4504 N == NumValuedInsts |
| 4505 </pre> |
| 4506 <p><strong>Updates</strong>:</p> |
| 4507 <pre class="prettyprint"> |
| 4508 ++NumValuedInsts; |
| 4509 TypeOf(%vN) = T2; |
| 4510 </pre> |
| 4511 <p><strong>Examples</strong>:</p> |
| 4512 <pre class="prettyprint"> |
| 4513 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4514 48:0| 3: <1, 6> | count 6; |
| 4515 50:4| 3: <3> | @t0 = float; |
| 4516 52:2| 3: <7, 64> | @t1 = i64; |
| 4517 55:4| 3: <2> | @t2 = void; |
| 4518 57:2| 3: <21, 0, 2, 0, 1> | @t3 = void (float, i64); |
| 4519 62:0| 3: <7, 32> | @t4 = i32; |
| 4520 65:2| 3: <4> | @t5 = double; |
| 4521 67:0| 0: <65534> | } |
| 4522 ... |
| 4523 100:0| 1: <65535, 12, 2> | function void @f0(float %p0, i64
%p1) |
| 4524 | | { // BlockID = 12 |
| 4525 108:0| 3: <1, 1> | blocks 1; |
| 4526 | | %b0: |
| 4527 110:4| 3: <3, 2, 4, 11> | %v0 = bitcast float %p0 to i32; |
| 4528 114:4| 3: <3, 2, 5, 11> | %v1 = bitcast i64 %p1 to double; |
| 4529 118:4| 3: <10> | ret void; |
| 4530 120:2| 0: <65534> | } |
| 4531 </pre> |
| 4532 <h2 id="comparison-instructions"><span id="link-for-compare-instructions"></span
>Comparison Instructions</h2> |
| 4533 <p>The comparisoninstructions compares values returns a boolean (i1) result for |
| 4534 each pair of compared values. There are different comparison operations for |
| 4535 integer and floating point values.</p> |
| 4536 <h3 id="integer-comparison-instructions">Integer Comparison Instructions</h3> |
| 4537 <p>The integer comparison instruction compares integer values and returns a |
| 4538 boolean (i1) result for each pair of compared values.</p> |
| 4539 <p><strong>Syntax</strong>:</p> |
| 4540 <pre class="prettyprint"> |
| 4541 %vN = icmp C T V1, V2; <A> |
| 4542 </pre> |
| 4543 <p><strong>Record</strong>:</p> |
| 4544 <pre class="prettyprint"> |
| 4545 AA: <9, VV1, VV2, CC> |
| 4546 </pre> |
| 4547 <p><strong>Semantics</strong>:</p> |
| 4548 <p>The integer comparison instruction compares integer values and returns a bool
ean |
| 4549 (i1) result for each pair of compared values in <code>V1</code> and <code>V2</co
de>. <code>V1</code> and |
| 4550 <code>V2</code> must be of type <code>T</code>. <code>T</code> must be an intege
r type, or an integer |
| 4551 vector type. Condition code <code>C</code> is the condition applied to all eleme
nts in |
| 4552 <code>V1</code> and <code>V2</code>. Each comparison always yields an i1. If <c
ode>T</code> is a primitive |
| 4553 type, the resulting type is i1. If <code>T</code> is a vector, then the resultin
g type is |
| 4554 a vector of i1 with the same size as <code>T</code>.</p> |
| 4555 <p>Legal test conditions are:</p> |
| 4556 <table border="1" class="docutils"> |
| 4557 <colgroup> |
| 4558 </colgroup> |
| 4559 <thead valign="bottom"> |
| 4560 <tr class="row-odd"><th class="head">C</th> |
| 4561 <th class="head">CC</th> |
| 4562 <th class="head">Operator</th> |
| 4563 </tr> |
| 4564 </thead> |
| 4565 <tbody valign="top"> |
| 4566 <tr class="row-even"><td>eq</td> |
| 4567 <td>32</td> |
| 4568 <td>equal</td> |
| 4569 </tr> |
| 4570 <tr class="row-odd"><td>ne</td> |
| 4571 <td>33</td> |
| 4572 <td>not equal</td> |
| 4573 </tr> |
| 4574 <tr class="row-even"><td>ugt</td> |
| 4575 <td>34</td> |
| 4576 <td>unsigned greater than</td> |
| 4577 </tr> |
| 4578 <tr class="row-odd"><td>uge</td> |
| 4579 <td>35</td> |
| 4580 <td>unsigned greater than or equal</td> |
| 4581 </tr> |
| 4582 <tr class="row-even"><td>ult</td> |
| 4583 <td>36</td> |
| 4584 <td>unsigned less then</td> |
| 4585 </tr> |
| 4586 <tr class="row-odd"><td>ule</td> |
| 4587 <td>37</td> |
| 4588 <td>unsigned less than or equal</td> |
| 4589 </tr> |
| 4590 <tr class="row-even"><td>sgt</td> |
| 4591 <td>38</td> |
| 4592 <td>signed greater than</td> |
| 4593 </tr> |
| 4594 <tr class="row-odd"><td>sge</td> |
| 4595 <td>39</td> |
| 4596 <td>signed greater than or equal</td> |
| 4597 </tr> |
| 4598 <tr class="row-even"><td>slt</td> |
| 4599 <td>40</td> |
| 4600 <td>signed less than</td> |
| 4601 </tr> |
| 4602 <tr class="row-odd"><td>sle</td> |
| 4603 <td>41</td> |
| 4604 <td>signed less than or equal</td> |
| 4605 </tr> |
| 4606 </tbody> |
| 4607 </table> |
| 4608 <p><strong>Constraints</strong>:</p> |
| 4609 <pre class="prettyprint"> |
| 4610 AA == AbbrevIndex(A) & |
| 4611 IsInteger(UnderlyingType(T) & |
| 4612 T == TypeOf(V1) == TypeOf(V2) & |
| 4613 N == NumValuedInsts |
| 4614 </pre> |
| 4615 <p><strong>Updates</strong>:</p> |
| 4616 <pre class="prettyprint"> |
| 4617 ++NumValuedInsts; |
| 4618 if IsVector(T) then |
| 4619 TypeOf(%vN) = <UnderlyingCount(T), i1> |
| 4620 else |
| 4621 TypeOf(%vN) = i1 |
| 4622 endif |
| 4623 </pre> |
| 4624 <p><strong>Examples</strong>:</p> |
| 4625 <pre class="prettyprint"> |
| 4626 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4627 48:0| 3: <1, 4> | count 4; |
| 4628 50:4| 3: <7, 32> | @t0 = i32; |
| 4629 53:6| 3: <7, 1> | @t1 = i1; |
| 4630 56:2| 3: <2> | @t2 = void; |
| 4631 58:0| 3: <21, 0, 2> | @t3 = void (); |
| 4632 61:2| 0: <65534> | } |
| 4633 ... |
| 4634 108:0| 1: <65535, 12, 2> | function void @f0() { |
| 4635 | | // BlockID = 12 |
| 4636 116:0| 3: <1, 1> | blocks 1; |
| 4637 118:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 4638 128:0| 3: <1, 0> | i32: |
| 4639 130:4| 3: <4, 0> | %c0 = i32 0; |
| 4640 133:0| 3: <4, 2> | %c1 = i32 1; |
| 4641 135:4| 0: <65534> | } |
| 4642 | | %b0: |
| 4643 136:0| 3: <28, 2, 1, 32> | %v0 = icmp eq i32 %c0, %c1; |
| 4644 140:6| 3: <28, 3, 2, 33> | %v1 = icmp ne i32 %c0, %c1; |
| 4645 145:4| 3: <28, 4, 3, 34> | %v2 = icmp ugt i32 %c0, %c1; |
| 4646 150:2| 3: <28, 5, 4, 36> | %v3 = icmp ult i32 %c0, %c1; |
| 4647 155:0| 3: <28, 6, 5, 37> | %v4 = icmp ule i32 %c0, %c1; |
| 4648 159:6| 3: <28, 7, 6, 38> | %v5 = icmp sgt i32 %c0, %c1; |
| 4649 164:4| 3: <28, 8, 7, 38> | %v6 = icmp sgt i32 %c0, %c1; |
| 4650 169:2| 3: <28, 9, 8, 39> | %v7 = icmp sge i32 %c0, %c1; |
| 4651 174:0| 3: <28, 10, 9, 40> | %v8 = icmp slt i32 %c0, %c1; |
| 4652 178:6| 3: <28, 11, 10, 41> | %v9 = icmp sle i32 %c0, %c1; |
| 4653 183:4| 3: <10> | ret void; |
| 4654 185:2| 0: <65534> | } |
| 4655 </pre> |
| 4656 <h3 id="floating-point-comparison-instructions">Floating Point Comparison Instru
ctions</h3> |
| 4657 <p>The floating point comparison instruction compares floating point values and |
| 4658 returns a boolean (i1) result for each pair of compared values.</p> |
| 4659 <p><strong>Syntax</strong>:</p> |
| 4660 <pre class="prettyprint"> |
| 4661 %vN = fcmp C T V1, V2; <A> |
| 4662 </pre> |
| 4663 <p><strong>Record</strong>:</p> |
| 4664 <pre class="prettyprint"> |
| 4665 AA: <9, VV1, VV2, CC> |
| 4666 </pre> |
| 4667 <p><strong>Semantics</strong>:</p> |
| 4668 <p>The floating point comparison instruciton compares floating point values and |
| 4669 returns a boolean (i1) result for each pair of compared values in <code>V1</code
> and |
| 4670 <code>V2</code>. <code>V1</code> and <code>V2</code> must be of type <code>T</co
de>. <code>T</code> must be a floating point |
| 4671 type, or a floating point vector type. Condition code <code>C</code> is the cond
ition |
| 4672 applied to all elements in <code>V1</code> and <code>V2</code>. Each comparison
always yields an |
| 4673 i1. If <code>T</code> is a primitive type, the resulting type is i1. If <code>T<
/code> is a |
| 4674 vector, then the resulting type is a vector of i1 with the same size as <code>T<
/code>.</p> |
| 4675 <p>Legal test conditions are:</p> |
| 4676 <table border="1" class="docutils"> |
| 4677 <colgroup> |
| 4678 </colgroup> |
| 4679 <thead valign="bottom"> |
| 4680 <tr class="row-odd"><th class="head">C</th> |
| 4681 <th class="head">CC</th> |
| 4682 <th class="head">Operator</th> |
| 4683 </tr> |
| 4684 </thead> |
| 4685 <tbody valign="top"> |
| 4686 <tr class="row-even"><td>false</td> |
| 4687 <td>0</td> |
| 4688 <td>Always false</td> |
| 4689 </tr> |
| 4690 <tr class="row-odd"><td>oeq</td> |
| 4691 <td>1</td> |
| 4692 <td>Ordered and equal</td> |
| 4693 </tr> |
| 4694 <tr class="row-even"><td>ogt</td> |
| 4695 <td>2</td> |
| 4696 <td>Ordered and greater than</td> |
| 4697 </tr> |
| 4698 <tr class="row-odd"><td>oge</td> |
| 4699 <td>3</td> |
| 4700 <td>Ordered and greater than or equal</td> |
| 4701 </tr> |
| 4702 <tr class="row-even"><td>olt</td> |
| 4703 <td>4</td> |
| 4704 <td>Ordered and less than</td> |
| 4705 </tr> |
| 4706 <tr class="row-odd"><td>ole</td> |
| 4707 <td>5</td> |
| 4708 <td>Ordered and less than or equal</td> |
| 4709 </tr> |
| 4710 <tr class="row-even"><td>one</td> |
| 4711 <td>6</td> |
| 4712 <td>Ordered and not equal</td> |
| 4713 </tr> |
| 4714 <tr class="row-odd"><td>ord</td> |
| 4715 <td>7</td> |
| 4716 <td>Ordered (no nans)</td> |
| 4717 </tr> |
| 4718 <tr class="row-even"><td>uno</td> |
| 4719 <td>8</td> |
| 4720 <td>Unordered (either nans)</td> |
| 4721 </tr> |
| 4722 <tr class="row-odd"><td>ueq</td> |
| 4723 <td>9</td> |
| 4724 <td>Unordered or equal</td> |
| 4725 </tr> |
| 4726 <tr class="row-even"><td>ugt</td> |
| 4727 <td>10</td> |
| 4728 <td>Unordered or greater than</td> |
| 4729 </tr> |
| 4730 <tr class="row-odd"><td>uge</td> |
| 4731 <td>11</td> |
| 4732 <td>Unordered or greater than or equal</td> |
| 4733 </tr> |
| 4734 <tr class="row-even"><td>ult</td> |
| 4735 <td>12</td> |
| 4736 <td>Unordered or less than</td> |
| 4737 </tr> |
| 4738 <tr class="row-odd"><td>ule</td> |
| 4739 <td>13</td> |
| 4740 <td>Unordered or less than or equal</td> |
| 4741 </tr> |
| 4742 <tr class="row-even"><td>une</td> |
| 4743 <td>14</td> |
| 4744 <td>Unordered or not equal</td> |
| 4745 </tr> |
| 4746 <tr class="row-odd"><td>true</td> |
| 4747 <td>15</td> |
| 4748 <td>Always true</td> |
| 4749 </tr> |
| 4750 </tbody> |
| 4751 </table> |
| 4752 <p><strong>Constraints</strong>:</p> |
| 4753 <pre class="prettyprint"> |
| 4754 AA == AbbrevIndex(A) & |
| 4755 IsFloat(UnderlyingType(T) & |
| 4756 T == TypeOf(V1) == TypeOf(V2) & |
| 4757 N == NumValuedInsts |
| 4758 </pre> |
| 4759 <p><strong>Updates</strong>:</p> |
| 4760 <pre class="prettyprint"> |
| 4761 ++NumValuedInsts; |
| 4762 if IsVector(T) then |
| 4763 TypeOf(%vN) = <UnderlyingCount(T), i1> |
| 4764 else |
| 4765 TypeOf(%vN) = i1 |
| 4766 endif |
| 4767 </pre> |
| 4768 <p><strong>Examples</strong>:</p> |
| 4769 <pre class="prettyprint"> |
| 4770 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4771 48:0| 3: <1, 4> | count 4; |
| 4772 50:4| 3: <3> | @t0 = float; |
| 4773 52:2| 3: <7, 1> | @t1 = i1; |
| 4774 54:6| 3: <2> | @t2 = void; |
| 4775 56:4| 3: <21, 0, 2> | @t3 = void (); |
| 4776 59:6| 0: <65534> | } |
| 4777 ... |
| 4778 108:0| 1: <65535, 12, 2> | function void @f0() { |
| 4779 | | // BlockID = 12 |
| 4780 116:0| 3: <1, 1> | blocks 1; |
| 4781 118:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 4782 128:0| 3: <1, 0> | float: |
| 4783 130:4| 3: <6, 0> | %c0 = float 0; |
| 4784 133:0| 3: <6, 1065353216> | %c1 = float 1; |
| 4785 139:2| 0: <65534> | } |
| 4786 | | %b0: |
| 4787 140:0| 3: <28, 2, 1, 0> | %v0 = fcmp false float %c0, %c1; |
| 4788 144:0| 3: <28, 3, 2, 1> | %v1 = fcmp oeq float %c0, %c1; |
| 4789 148:0| 3: <28, 4, 3, 2> | %v2 = fcmp ogt float %c0, %c1; |
| 4790 152:0| 3: <28, 5, 4, 3> | %v3 = fcmp oge float %c0, %c1; |
| 4791 156:0| 3: <28, 6, 5, 4> | %v4 = fcmp olt float %c0, %c1; |
| 4792 160:0| 3: <28, 7, 6, 5> | %v5 = fcmp ole float %c0, %c1; |
| 4793 164:0| 3: <28, 8, 7, 6> | %v6 = fcmp one float %c0, %c1; |
| 4794 168:0| 3: <28, 9, 8, 7> | %v7 = fcmp ord float %c0, %c1; |
| 4795 172:0| 3: <28, 10, 9, 9> | %v8 = fcmp ueq float %c0, %c1; |
| 4796 176:0| 3: <28, 11, 10, 10> | %v9 = fcmp ugt float %c0, %c1; |
| 4797 180:0| 3: <28, 12, 11, 11> | %v10 = fcmp uge float %c0, %c1; |
| 4798 184:0| 3: <28, 13, 12, 12> | %v11 = fcmp ult float %c0, %c1; |
| 4799 188:0| 3: <28, 14, 13, 13> | %v12 = fcmp ule float %c0, %c1; |
| 4800 192:0| 3: <28, 15, 14, 14> | %v13 = fcmp une float %c0, %c1; |
| 4801 196:0| 3: <28, 16, 15, 8> | %v14 = fcmp uno float %c0, %c1; |
| 4802 200:0| 3: <28, 17, 16, 15> | %v15 = fcmp true float %c0, %c1; |
| 4803 204:0| 3: <10> | ret void; |
| 4804 205:6| 0: <65534> | } |
| 4805 208:0|0: <65534> |} |
| 4806 </pre> |
| 4807 <h2 id="vector-instructions"><span id="link-for-vector-instructions"></span>Vect
or Instructions</h2> |
| 4808 <p>PNaClAsm supports several instructions that process vectors. This includes th
e |
| 4809 <a class="reference internal" href="#link-for-integer-binary-instructions"><em>i
nteger</em></a> and <a class="reference internal" href="#link-for-floating-point
-binary-instructions"><em>floating |
| 4810 point</em></a> binary instructions as well |
| 4811 as <a class="reference internal" href="#link-for-compare-instructions"><em>compa
re</em></a> instructions. These |
| 4812 instructions work with vectors and generate resulting (new) vectors. This |
| 4813 section introduces the instructions to construct vectors and extract results.</p
> |
| 4814 <h3 id="insert-element-instruction"><span id="link-for-insert-element-instructio
n-section"></span>Insert Element Instruction</h3> |
| 4815 <p>The <em>insert element</em> instruction inserts a scalar value into a vector
at a |
| 4816 specified index. The <em>insert element</em> instruction takes an existing vecto
r and |
| 4817 puts a scalar value in one of the elements of the vector.</p> |
| 4818 <p>The <em>insert element</em> instruction can be used to construct a vector, on
e element |
| 4819 at a time. At first glance, it may appear that one can’t construct a vect
or, |
| 4820 since the <em>insert element</em> instruction needs a vector to insert elements
into.</p> |
| 4821 <p>The key to understanding vector construction is understand that one can creat
e |
| 4822 an <a class="reference internal" href="#link-for-undefined-literal"><em>undefine
d</em></a> vector literal. Using that |
| 4823 constant as a starting point, one can built up the wanted vector by a sequence |
| 4824 of <em>insert element</em> instructions.</p> |
| 4825 <p><strong>Syntax</strong>:</p> |
| 4826 <pre class="prettyprint"> |
| 4827 %vN = insertelement TV V, TE E, i32 I; <A> |
| 4828 </pre> |
| 4829 <p><strong>Record</strong>:</p> |
| 4830 <pre class="prettyprint"> |
| 4831 AA: <7, VV, EE, II> |
| 4832 </pre> |
| 4833 <p><strong>Semantics</strong>:</p> |
| 4834 <p>The <em>insert element</em> instruction inserts scalar value <code>E</code> i
nto index <code>I</code> of |
| 4835 vector <code>V</code>. <code>%vN</code> holds the updated vector. Type <code>TV<
/code> is the type of |
| 4836 vector. It is also the type of updated vector <code>%vN</code>. Type <code>TE<
/code> is the type |
| 4837 of scalar value <code>E</code> and must be the element type of vector <code>V</c
ode>. <code>I</code> must |
| 4838 be an <a class="reference internal" href="#link-for-integer-literal"><em>i32 lit
eral</em></a>.</p> |
| 4839 <p>If <code>I</code> exceeds the length of <code>V</code>, the result is undefin
ed.</p> |
| 4840 <p><strong>Constraints</strong>:</p> |
| 4841 <pre class="prettyprint"> |
| 4842 AA == AbbrevIndex(A) & |
| 4843 IsVector(TV) & |
| 4844 TypeOf(V) == TV & |
| 4845 UnderlyingType(TV) == TE & |
| 4846 TypeOf(I) == i32 & |
| 4847 N == NumValuedInsts |
| 4848 </pre> |
| 4849 <p><strong>Updates</strong>:</p> |
| 4850 <pre class="prettyprint"> |
| 4851 ++NumValuedInsts; |
| 4852 TypeOf(%vN) = TV; |
| 4853 </pre> |
| 4854 <p><strong>Examples</strong>:</p> |
| 4855 <pre class="prettyprint"> |
| 4856 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4857 48:0| 3: <1, 5> | count 5; |
| 4858 50:4| 3: <7, 1> | @t0 = i1; |
| 4859 53:0| 3: <12, 4, 0> | @t1 = <4 x i1>; |
| 4860 56:2| 3: <7, 32> | @t2 = i32; |
| 4861 59:4| 3: <2> | @t3 = void; |
| 4862 61:2| 3: <21, 0, 3> | @t4 = void (); |
| 4863 64:4| 0: <65534> | } |
| 4864 ... |
| 4865 116:0| 1: <65535, 12, 2> | function void @f0() { |
| 4866 | | // BlockID = 12 |
| 4867 124:0| 3: <1, 1> | blocks 1; |
| 4868 126:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 4869 136:0| 3: <1, 0> | i1: |
| 4870 138:4| 3: <4, 0> | %c0 = i1 0; |
| 4871 141:0| 3: <4, 3> | %c1 = i1 1; |
| 4872 143:4| 3: <1, 1> | <4 x i1>: |
| 4873 146:0| 3: <3> | %c2 = <4 x i1> undef; |
| 4874 147:6| 3: <1, 2> | i32: |
| 4875 150:2| 3: <4, 0> | %c3 = i32 0; |
| 4876 152:6| 3: <4, 2> | %c4 = i32 1; |
| 4877 155:2| 3: <4, 4> | %c5 = i32 2; |
| 4878 157:6| 3: <4, 6> | %c6 = i32 3; |
| 4879 160:2| 0: <65534> | } |
| 4880 | | %b0: |
| 4881 164:0| 3: <7, 5, 7, 4> | %v0 = insertelement <4 x i1&g
t; %c2, |
| 4882 | | i1 %c0, i32 %c3; |
| 4883 168:0| 3: <7, 1, 7, 4> | %v1 = insertelement <4 x i1&g
t; %v0, |
| 4884 | | i1 %c1, i32 %c4; |
| 4885 172:0| 3: <7, 1, 9, 4> | %v2 = insertelement <4 x i1&g
t; %v1, |
| 4886 | | i1 %c0, i32 %c5; |
| 4887 176:0| 3: <7, 1, 9, 4> | %v3 = insertelement <4 x i1&g
t; %v2, |
| 4888 | | i1 %c1, i32 %c6; |
| 4889 180:0| 3: <10> | ret void; |
| 4890 181:6| 0: <65534> | } |
| 4891 </pre> |
| 4892 <h3 id="extract-element-instruction">Extract Element Instruction</h3> |
| 4893 <p>The <em>extract element</em> instruction extracts a single scalar value from
a vector |
| 4894 at a specified index.</p> |
| 4895 <p><strong>Syntax</strong>:</p> |
| 4896 <pre class="prettyprint"> |
| 4897 %vN = extractelement TV V, i32 I; <A> |
| 4898 </pre> |
| 4899 <p><strong>Record</strong>:</p> |
| 4900 <pre class="prettyprint"> |
| 4901 AA: <6, VV, II> |
| 4902 </pre> |
| 4903 <p><strong>Semantics</strong>:</p> |
| 4904 <p>The <em>extract element</em> instruction extracts the scalar value at index <
code>I</code> from |
| 4905 vector <code>V</code>. The extracted value is assigned to <code>%vN</code>. Type
<code>TV</code> is the |
| 4906 type of vector <code>V</code>. <code>I</code> must be an <a class="reference int
ernal" href="#link-for-integer-literal"><em>i32 |
| 4907 literal</em></a>. The type of <code>vN</code> must be the element type |
| 4908 of vector <code>V</code>.</p> |
| 4909 <p>If <code>I</code> exceeds the length of <code>V</code>, the result is undefin
ed.</p> |
| 4910 <p><strong>Constraints</strong>:</p> |
| 4911 <pre class="prettyprint"> |
| 4912 AA == AbbrevIndex(A) & |
| 4913 IsVector(TV) & |
| 4914 TypeOf(V) == TV & |
| 4915 TypeOf(I) == i32 & |
| 4916 N == NumValuedInsts |
| 4917 </pre> |
| 4918 <p><strong>Updates</strong>:</p> |
| 4919 <pre class="prettyprint"> |
| 4920 ++NumValuedInsts; |
| 4921 TypeOf(%vN) = UnderlyingType(TV); |
| 4922 </pre> |
| 4923 <p><strong>Examples</strong>:</p> |
| 4924 <pre class="prettyprint"> |
| 4925 96:0| 1: <65535, 12, 2> | function void @f0(<4 x i32>
; %p0) { |
| 4926 | | // BlockID = 12 |
| 4927 104:0| 3: <1, 1> | blocks 1; |
| 4928 106:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 4929 116:0| 3: <1, 0> | i32: |
| 4930 118:4| 3: <4, 0> | %c0 = i32 0; |
| 4931 121:0| 0: <65534> | } |
| 4932 | | %b0: |
| 4933 124:0| 3: <6, 2, 1> | %v0 = |
| 4934 | | extractelement <4 x i32> %p0, |
| 4935 | | i32 %c0; |
| 4936 127:2| 3: <10> | ret void; |
| 4937 129:0| 0: <65534> | } |
| 4938 </pre> |
| 4939 <h2 id="other-instructions"><span id="link-for-other-pnaclasm-instructions"></sp
an>Other Instructions</h2> |
| 4940 <p>This section defines miscellaneous instructions which defy better |
| 4941 classification.</p> |
| 4942 <h3 id="forward-type-declaration"><span id="link-for-forward-type-declaration-se
ction"></span>Forward Type Declaration</h3> |
| 4943 <p>The forward type declaration exists to deal with the fact that all instructio
n |
| 4944 values must have a type associated with them before they are used. For some |
| 4945 simple functions one can easily topologically sort instructions so that |
| 4946 instruction values are defined before they are used. However, if the |
| 4947 implementation contains loops, the loop induced values can’t be defined be
fore |
| 4948 they are used.</p> |
| 4949 <p>The solution is to forward declare the type of an instruction value. One coul
d |
| 4950 forward declare the types of all instructions at the beginning of the function |
| 4951 block. However, this would make the corresponding file size considerably |
| 4952 larger. Rather, one should only generate these forward type declarations |
| 4953 sparingly and only when needed.</p> |
| 4954 <p><strong>Syntax</strong>:</p> |
| 4955 <pre class="prettyprint"> |
| 4956 declare T %vN; <A> |
| 4957 </pre> |
| 4958 <p><strong>Record</strong>:</p> |
| 4959 <pre class="prettyprint"> |
| 4960 AA: <43, N, TT> |
| 4961 </pre> |
| 4962 <p><strong>Semantics</strong>:</p> |
| 4963 <p>The forward declare type declaration defines the type to be associated with a |
| 4964 (not yet defined) instruction value <code>%vN</code>. <code>T</code> is the type
of the value |
| 4965 generated by the <code>Nth</code> value generating instruction in the function b
lock.</p> |
| 4966 <p>Note: It is an error to define the type of <code>%vN</code> with a different
type than |
| 4967 will be generated by the <code>Nth</code> value generating instruction in the fu
nction |
| 4968 block.</p> |
| 4969 <p>Also note that this construct is a declaration and not considered an |
| 4970 instruction, even though it appears in the list of instruction records. Hence, |
| 4971 they may appear before and between <a class="reference internal" href="#link-for
-phi-instruction-section"><em>phi</em></a> |
| 4972 instructions in a basic block.</p> |
| 4973 <p><strong>Constraints</strong>:</p> |
| 4974 <pre class="prettyprint"> |
| 4975 AA = AbbrevIndex(A) & |
| 4976 TT = TypeID(T) |
| 4977 </pre> |
| 4978 <p><strong>Updates</strong>:</p> |
| 4979 <pre class="prettyprint"> |
| 4980 TypeOf(%vN) = T; |
| 4981 </pre> |
| 4982 <p><strong>Examples</strong>:</p> |
| 4983 <pre class="prettyprint"> |
| 4984 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 4985 48:0| 3: <1, 4> | count 4; |
| 4986 50:4| 3: <7, 32> | @t0 = i32; |
| 4987 53:6| 3: <2> | @t1 = void; |
| 4988 55:4| 3: <7, 1> | @t2 = i1; |
| 4989 58:0| 3: <21, 0, 1, 0> | @t3 = void (i32); |
| 4990 62:0| 0: <65534> | } |
| 4991 ... |
| 4992 108:0| 1: <65535, 12, 2> | function void @f0(i32 %p0) { |
| 4993 | | // BlockID = 12 |
| 4994 116:0| 3: <1, 7> | blocks 7; |
| 4995 118:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 4996 128:0| 3: <1, 2> | i1: |
| 4997 130:4| 3: <4, 3> | %c0 = i1 1; |
| 4998 133:0| 0: <65534> | } |
| 4999 | | %b0: |
| 5000 136:0| 3: <11, 4> | br label %b4; |
| 5001 | | %b1: |
| 5002 138:4| 3: <43, 6, 0> | declare i32 %v3; |
| 5003 142:4| 3: <2, 2, 4294967293, 0> | %v0 = add i32 %p0, %v3; |
| 5004 151:0| 3: <11, 6> | br label %b6; |
| 5005 | | %b2: |
| 5006 153:4| 3: <43, 7, 0> | declare i32 %v4; |
| 5007 157:4| 3: <2, 3, 4294967293, 0> | %v1 = add i32 %p0, %v4; |
| 5008 166:0| 3: <11, 6> | br label %b6; |
| 5009 | | %b3: |
| 5010 168:4| 3: <2, 4, 4294967295, 0> | %v2 = add i32 %p0, %v3; |
| 5011 177:0| 3: <11, 6> | br label %b6; |
| 5012 | | %b4: |
| 5013 179:4| 3: <2, 5, 5, 0> | %v3 = add i32 %p0, %p0; |
| 5014 183:4| 3: <11, 1, 5, 5> | br i1 %c0, label %b1, label %b5; |
| 5015 | | %b5: |
| 5016 187:4| 3: <2, 1, 6, 0> | %v4 = add i32 %v3, %p0; |
| 5017 191:4| 3: <11, 2, 3, 6> | br i1 %c0, label %b2, label %b3; |
| 5018 | | %b6: |
| 5019 195:4| 3: <10> | ret void; |
| 5020 197:2| 0: <65534> | } |
| 5021 </pre> |
| 5022 <h3 id="phi-instruction"><span id="link-for-phi-instruction-section"></span>Phi
Instruction</h3> |
| 5023 <p>The <em>phi</em> instruction is used to implement phi nodes in the SSA graph |
| 5024 representing the function. Phi instructions can only appear at the beginning of |
| 5025 a basic block. There must be no non-phi instructions (other than forward type |
| 5026 declarations) between the start of the basic block and the <em>phi</em> instruct
ion.</p> |
| 5027 <p>To clarify the origin of each incoming value, the incoming value is associate
d |
| 5028 with the incoming edge from the corresponding predecessor block that the |
| 5029 incoming value comes from.</p> |
| 5030 <p><strong>Syntax</strong>:</p> |
| 5031 <pre class="prettyprint"> |
| 5032 %vN = phi T [V1, %bB1], ... , [VM, %bBM]; <A> |
| 5033 </pre> |
| 5034 <p><strong>Record</strong>:</p> |
| 5035 <pre class="prettyprint"> |
| 5036 AA: <16, TT, VV1, B1, ..., VVM, BM> |
| 5037 </pre> |
| 5038 <p><strong>Semantics</strong>:</p> |
| 5039 <p>The phi instruction is used to implement phi nodes in the SSA graph represent
ing |
| 5040 the function. <code>%vN</code> is the resulting value of the corresponding phi n
ode. <code>T</code> is |
| 5041 the type of the phi node. Values <code>V1</code> through <code>VM</code> are the
reaching definitions |
| 5042 for the phi node while <code>%bB1</code> through <code>%bBM</code> are the corre
sponding predecessor |
| 5043 blocks. Each <code>VI</code> reaches via the incoming predecessor edge from blo
ck <code>%bBI</code> |
| 5044 (for 1 <= I <= M). Type <code>T</code> must be the type associated with ea
ch <code>VI</code>.</p> |
| 5045 <p><strong>Constraints</strong>:</p> |
| 5046 <pre class="prettyprint"> |
| 5047 AA == AbbrevIndex(A) & |
| 5048 M > 1 & |
| 5049 TT == TypeID(T) & |
| 5050 T = TypeOf(VI) for all I, 1 <= I <= M & |
| 5051 BI < ExpectedBasicBlocks for all I, 1 <= I <= M & |
| 5052 VVI = SignRotate(RelativeIndex(VI)) for all I, 1 <= I <= M & |
| 5053 N == NumValuedInsts |
| 5054 </pre> |
| 5055 <p><strong>Updates</strong>:</p> |
| 5056 <pre class="prettyprint"> |
| 5057 ++NumValuedInsts; |
| 5058 TypeOf(%vN) = T; |
| 5059 </pre> |
| 5060 <p><strong>Examples</strong>:</p> |
| 5061 <pre class="prettyprint"> |
| 5062 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 5063 48:0| 3: <1, 4> | count 4; |
| 5064 50:4| 3: <7, 32> | @t0 = i32; |
| 5065 53:6| 3: <2> | @t1 = void; |
| 5066 55:4| 3: <21, 0, 1> | @t2 = void (); |
| 5067 58:6| 3: <7, 1> | @t3 = i1; |
| 5068 61:2| 0: <65534> | } |
| 5069 ... |
| 5070 112:0| 1: <65535, 12, 2> | function void @f0() { |
| 5071 | | // BlockID = 12 |
| 5072 120:0| 3: <1, 4> | blocks 4; |
| 5073 122:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 5074 132:0| 3: <1, 0> | i32: |
| 5075 134:4| 3: <4, 2> | %c0 = i32 1; |
| 5076 137:0| 3: <1, 3> | i1: |
| 5077 139:4| 3: <4, 0> | %c1 = i1 0; |
| 5078 142:0| 0: <65534> | } |
| 5079 | | %b0: |
| 5080 144:0| 3: <11, 1, 2, 1> | br i1 %c1, label %b1, label %b2; |
| 5081 | | %b1: |
| 5082 148:0| 3: <2, 2, 2, 0> | %v0 = add i32 %c0, %c0; |
| 5083 152:0| 3: <2, 3, 3, 1> | %v1 = sub i32 %c0, %c0; |
| 5084 156:0| 3: <11, 3> | br label %b3; |
| 5085 | | %b2: |
| 5086 158:4| 3: <2, 4, 4, 2> | %v2 = mul i32 %c0, %c0; |
| 5087 162:4| 3: <2, 5, 5, 3> | %v3 = udiv i32 %c0, %c0; |
| 5088 166:4| 3: <11, 3> | br label %b3; |
| 5089 | | %b3: |
| 5090 169:0| 3: <16, 0, 8, 1, 4, 2> | %v4 = phi i32 [%v0, %b1], |
| 5091 | | [%v2, %b2]; |
| 5092 174:4| 3: <16, 0, 8, 1, 4, 2> | %v5 = phi i32 [%v1, %b1], |
| 5093 | | [%v3, %b2]; |
| 5094 180:0| 3: <10> | ret void; |
| 5095 181:6| 0: <65534> | } |
| 5096 </pre> |
| 5097 <h3 id="select-instruction">Select Instruction</h3> |
| 5098 <p>The <em>select</em> instruction is used to choose between pairs of values, ba
sed on a |
| 5099 condition, without PNaClAsm-level branching.</p> |
| 5100 <p><strong>Syntax</strong>:</p> |
| 5101 <pre class="prettyprint"> |
| 5102 %vN = select CT C, T V1, T V2; <A> |
| 5103 </pre> |
| 5104 <p><strong>Record</strong>:</p> |
| 5105 <pre class="prettyprint"> |
| 5106 AA: <29, VV1, VV2, CC> |
| 5107 </pre> |
| 5108 <p><strong>Semantics</strong>:</p> |
| 5109 <p>The <em>select</em> instruction chooses pairs of values <code>V1</code> and <
code>V2</code>, based on |
| 5110 condition value <code>C</code>. The type <code>CT</code> of value <code>C</code
> must either be an i1, or a |
| 5111 vector of type i1. The type of values <code>V1</code> and <code>V2</code> must b
e of type <code>T</code>. Type |
| 5112 <code>T</code> must either be a primitive type, or a vector of a primitive type.
</p> |
| 5113 <p>Both <code>CT</code> and <code>T</code> must be primitive types, or both must
be vector types of the |
| 5114 same size. When the contents of <code>C</code> is 1, the corresponding value fro
m <code>V1</code> will |
| 5115 be chosen. Otherwise the corresponding value from <code>V2</code> will be chosen
.</p> |
| 5116 <p><strong>Constraints</strong>:</p> |
| 5117 <pre class="prettyprint"> |
| 5118 AA == AbbrevIndex(A) & |
| 5119 CC == RelativeIndex(C) & |
| 5120 VV1 == RelativeIndex(V1) & |
| 5121 VV2 == RelativeIndex(V2) & |
| 5122 T == TypeOf(V1) == TypeOf(V2) & |
| 5123 UnderlyingType(CT) == i1 & |
| 5124 IsInteger(UnderlyingType(T)) or IsFloat(UnderlyingType(T)) & |
| 5125 UnderlyingCount(C) == UnderlyingCount(T) & |
| 5126 N == NumValuedInsts |
| 5127 </pre> |
| 5128 <p><strong>Updates</strong>:</p> |
| 5129 <pre class="prettyprint"> |
| 5130 ++NumValuedInsts; |
| 5131 TypeOf(%vN) = T; |
| 5132 </pre> |
| 5133 <p><strong>Examples</strong>:</p> |
| 5134 <pre class="prettyprint"> |
| 5135 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p
1) { |
| 5136 | | // BlockID = 12 |
| 5137 104:0| 3: <1, 1> | blocks 1; |
| 5138 106:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 5139 116:0| 3: <1, 2> | i1: |
| 5140 118:4| 3: <4, 3> | %c0 = i1 1; |
| 5141 121:0| 0: <65534> | } |
| 5142 | | %b0: |
| 5143 124:0| 3: <29, 3, 2, 1> | %v0 = select i1 %c0, i32 %p0, |
| 5144 | | i32 %p1; |
| 5145 128:0| 3: <10, 1> | ret i32 %v0; |
| 5146 130:4| 0: <65534> | } |
| 5147 </pre> |
| 5148 <h3 id="call-instructions">Call Instructions</h3> |
| 5149 <p>The <em>call</em> instruction does a function call. The call instruction is u
sed to |
| 5150 cause control flow to transfer to a specified routine, with its incoming |
| 5151 arguments bound to the specified values. When a return instruction in the called |
| 5152 function is reached, control flow continues with the instruction after the |
| 5153 function call. If the call is to a function, the returned value is the value |
| 5154 generated by the call instruction. Otherwise no result is defined by the call.</
p> |
| 5155 <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-t
ranslator"><em>PNaCl |
| 5156 translator</em></a> is free to perform tail call |
| 5157 optimization. That is, the <em>tail</em> flag is a hint that may be ignored by t
he |
| 5158 PNaCl translator.</p> |
| 5159 <p>There are two kinds of calls: <em>direct</em> and <em>indirect</em>. A <em>di
rect</em> call calls a |
| 5160 defined <a class="reference internal" href="#link-for-function-address-section">
<em>function address</em></a> (i.e. a |
| 5161 reference to a bitcode ID of the form <code>%fF</code>). All other calls are <em
>indirect</em>.</p> |
| 5162 <h4 id="direct-procedure-call">Direct Procedure Call</h4> |
| 5163 <p>The direct procedure call calls a defined <a class="reference internal" href=
"#link-for-function-address-section"><em>function |
| 5164 address</em></a> whose <a class="reference internal" href="#link-for-function-ty
pe"><em>type |
| 5165 signature</em></a> returns type void.</p> |
| 5166 <p><strong>Syntax</strong>:</p> |
| 5167 <pre class="prettyprint"> |
| 5168 TAIL call void @fF (T1 A1, ... , TN AN); <A> |
| 5169 </pre> |
| 5170 <p><strong>Record</strong>:</p> |
| 5171 <pre class="prettyprint"> |
| 5172 AA: <34, CC, F, AA1, ... , AAN> |
| 5173 </pre> |
| 5174 <p><strong>Semantics</strong>:</p> |
| 5175 <p>The direct procedure call calls a define function address <code>%fF</code> wh
ose type |
| 5176 signature return type is void. The arguments <code>A1</code> through <code>AN</c
ode> are passed |
| 5177 in the order specified. The type of argument <code>AI</code> must be type <code>
TI</code> (for all I, |
| 5178 1 <=I <= N). Flag <code>TAIL</code> is optional. If it is included, it mu
st be the |
| 5179 literal <code>tail</code>.</p> |
| 5180 <p>The types of the arguments must match the corresponding types of the function |
| 5181 signature associated with <code>%fF</code>. The return type of <code>%f</code> m
ust be void.</p> |
| 5182 <p>TAIL is encoded into calling convention value <code>CC</code> as follows:</p> |
| 5183 <table border="1" class="docutils"> |
| 5184 <colgroup> |
| 5185 </colgroup> |
| 5186 <thead valign="bottom"> |
| 5187 <tr class="row-odd"><th class="head">TAIL</th> |
| 5188 <th class="head">CC</th> |
| 5189 </tr> |
| 5190 </thead> |
| 5191 <tbody valign="top"> |
| 5192 <tr class="row-even"><td>“”</td> |
| 5193 <td>0</td> |
| 5194 </tr> |
| 5195 <tr class="row-odd"><td>“tail”</td> |
| 5196 <td>1</td> |
| 5197 </tr> |
| 5198 </tbody> |
| 5199 </table> |
| 5200 <p><strong>Constraints</strong>:</p> |
| 5201 <pre class="prettyprint"> |
| 5202 AA == AbbrevIndex(A) & |
| 5203 N >= 0 & |
| 5204 TypeOfFcn(%fF) == void (T1, ... , TN) & |
| 5205 TypeOf(AI) == TI for all I, 1 <= I <= N |
| 5206 </pre> |
| 5207 <p><strong>Updates</strong>:</p> |
| 5208 <pre class="prettyprint"> |
| 5209 ++NumValuedInsts; |
| 5210 </pre> |
| 5211 <p><strong>Examples</strong>:</p> |
| 5212 <pre class="prettyprint"> |
| 5213 72:0| 3: <8, 3, 0, 1, 0> | declare external |
| 5214 | | void @f0(i32, i64, i32); |
| 5215 ... |
| 5216 116:0| 1: <65535, 12, 2> | function void @f1(i32 %p0) { |
| 5217 | | // BlockID = 12 |
| 5218 124:0| 3: <1, 1> | blocks 1; |
| 5219 126:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 5220 136:0| 3: <1, 2> | i64: |
| 5221 138:4| 3: <4, 2> | %c0 = i64 1; |
| 5222 141:0| 0: <65534> | } |
| 5223 | | %b0: |
| 5224 144:0| 3: <34, 0, 4, 2, 1, 2> | call void |
| 5225 | | @f0(i32 %p0, i64 %c0, i32 %p0); |
| 5226 150:2| 3: <10> | ret void; |
| 5227 152:0| 0: <65534> | } |
| 5228 </pre> |
| 5229 <h4 id="direct-function-call">Direct Function Call</h4> |
| 5230 <p>The direct function call calls a defined function address whose type signatur
e |
| 5231 returns a value.</p> |
| 5232 <p><strong>Syntax</strong>:</p> |
| 5233 <pre class="prettyprint"> |
| 5234 %vN = TAIL call RT %fF (T1 A1, ... , TM AM); <A> |
| 5235 </pre> |
| 5236 <p><strong>Record</strong>:</p> |
| 5237 <pre class="prettyprint"> |
| 5238 AA: <34, CC, F, AA1, ... , AAM> |
| 5239 </pre> |
| 5240 <p><strong>Semantics</strong>:</p> |
| 5241 <p>The direct function call calls a defined function address <code>%fF</code> wh
ose type |
| 5242 signature returned is not type void. The arguments <code>A1</code> through <code
>AM</code> are |
| 5243 passed in the order specified. The type of argument <code>AI</code> must be type
<code>TI</code> |
| 5244 (for all I, 1 <= I <= N). Flag <code>TAIL</code> is optional. If it is in
cluded, it must |
| 5245 be the literal <code>tail</code>.</p> |
| 5246 <p>The types of the arguments must match the corresponding types of the function |
| 5247 signature associated with <code>%fF</code>. The return type must match <code>RT<
/code>.</p> |
| 5248 <p>Each parameter type <code>TI</code>, and return type <code>RT</code>, must ei
ther be a primitive type, |
| 5249 or a vector type. If the parameter type is an integer type, it must either be |
| 5250 i32 or i64.</p> |
| 5251 <p>TAIL is encoded into calling convention value <code>CC</code> as follows:</p> |
| 5252 <table border="1" class="docutils"> |
| 5253 <colgroup> |
| 5254 </colgroup> |
| 5255 <thead valign="bottom"> |
| 5256 <tr class="row-odd"><th class="head">TAIL</th> |
| 5257 <th class="head">CC</th> |
| 5258 </tr> |
| 5259 </thead> |
| 5260 <tbody valign="top"> |
| 5261 <tr class="row-even"><td>“”</td> |
| 5262 <td>0</td> |
| 5263 </tr> |
| 5264 <tr class="row-odd"><td>“tail”</td> |
| 5265 <td>1</td> |
| 5266 </tr> |
| 5267 </tbody> |
| 5268 </table> |
| 5269 <p><strong>Constraints</strong>:</p> |
| 5270 <pre class="prettyprint"> |
| 5271 AA == AbbrevIndex(A) & |
| 5272 N >= 0 & |
| 5273 TypeOfFcn(%fF) == RT (T1, ... , TN) & |
| 5274 TypeOf(AI) == TI for all I, 1 <= I <= M & |
| 5275 IsFcnArgType(TI) for all I, 1 <= I <= M & |
| 5276 IsFcnArgType(RT) & |
| 5277 N == NumValuedInsts |
| 5278 </pre> |
| 5279 <p><strong>Updates</strong>:</p> |
| 5280 <pre class="prettyprint"> |
| 5281 ++NumValuedInsts; |
| 5282 TypeOf(%vN) = RT; |
| 5283 </pre> |
| 5284 <p><strong>Examples</strong>:</p> |
| 5285 <pre class="prettyprint"> |
| 5286 72:0| 3: <8, 2, 0, 1, 0> | declare external |
| 5287 | | i32 @f0(i32, i64, i32); |
| 5288 ... |
| 5289 116:0| 1: <65535, 12, 2> | function i32 @f1(i32 %p0) { |
| 5290 | | // BlockID = 12 |
| 5291 124:0| 3: <1, 1> | blocks 1; |
| 5292 126:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 5293 136:0| 3: <1, 1> | i64: |
| 5294 138:4| 3: <4, 2> | %c0 = i64 1; |
| 5295 141:0| 0: <65534> | } |
| 5296 | | %b0: |
| 5297 144:0| 3: <34, 0, 4, 2, 1, 2> | %v0 = call i32 |
| 5298 | | @f0(i32 %p0, i64 %c0, i32 %p0); |
| 5299 150:2| 3: <34, 1, 4, 1> | %v1 = tail call i32 @f1(i32 %v
0); |
| 5300 155:0| 3: <10, 2> | ret i32 %v0; |
| 5301 157:4| 0: <65534> | } |
| 5302 </pre> |
| 5303 <h4 id="indirect-procedure-call">Indirect Procedure Call</h4> |
| 5304 <p>The indirect procedure call calls a function using an indirect function addre
ss, |
| 5305 and whose type signature is assumed to return type void. It is different from |
| 5306 the direct procedure call because we can’t use the type signature of the |
| 5307 corresponding direct function address to type check the construct.</p> |
| 5308 <p><strong>Syntax</strong>:</p> |
| 5309 <pre class="prettyprint"> |
| 5310 TAIL call void V (T1 A1, ... , TN AN); <A> |
| 5311 </pre> |
| 5312 <p><strong>Record</strong>:</p> |
| 5313 <pre class="prettyprint"> |
| 5314 AA: <44, CC, TV, VV, AA1, ... , AAN> |
| 5315 </pre> |
| 5316 <p><strong>Semantics</strong>:</p> |
| 5317 <p>The indirect call procedure calls a function using value <code>V</code> that
is an indirect |
| 5318 function address, and whose type signature is assumed to return type void. The |
| 5319 arguments <code>A1</code> through <code>AN</code> are passed in the order specif
ied. The type of |
| 5320 argument <code>AI</code> must be type <code>TI</code> (for all I, 1 <= I <
= N). Flag <code>TAIL</code> is |
| 5321 optional. If it is included, it must be the literal <code>tail</code>.</p> |
| 5322 <p>Each parameter type <code>TI</code> (1 <= I <= N) must either be a prim
itive type, or a |
| 5323 vector type. If the parameter type is an integer type, it must either be i32 |
| 5324 or i64.</p> |
| 5325 <p>TAIL is encoded into calling convention value <code>CC</code> as follows:</p> |
| 5326 <table border="1" class="docutils"> |
| 5327 <colgroup> |
| 5328 </colgroup> |
| 5329 <thead valign="bottom"> |
| 5330 <tr class="row-odd"><th class="head">TAIL</th> |
| 5331 <th class="head">CC</th> |
| 5332 </tr> |
| 5333 </thead> |
| 5334 <tbody valign="top"> |
| 5335 <tr class="row-even"><td>“”</td> |
| 5336 <td>0</td> |
| 5337 </tr> |
| 5338 <tr class="row-odd"><td>“tail”</td> |
| 5339 <td>1</td> |
| 5340 </tr> |
| 5341 </tbody> |
| 5342 </table> |
| 5343 <p>The type signature of the called procedure is assumed to be:</p> |
| 5344 <pre class="prettyprint"> |
| 5345 void (T1, ... , TN) |
| 5346 </pre> |
| 5347 <p>It isn’t necessary to define this type in the <a class="reference inter
nal" href="#link-for-types-block-section"><em>types |
| 5348 block</em></a>, since the type is inferred rather than |
| 5349 used.</p> |
| 5350 <p><strong>Constraints</strong>:</p> |
| 5351 <pre class="prettyprint"> |
| 5352 AA == AbbrevIndex(A) & |
| 5353 N >= 0 & |
| 5354 TV = TypeID(void) & |
| 5355 AbsoluteIndex(V) >= NumFuncAddresses & |
| 5356 TypeOf(AI) == TI for all I, 1 <= I <= N & |
| 5357 IsFcnArgType(TI) for all I, 1 <= I <= N |
| 5358 </pre> |
| 5359 <p><strong>Updates</strong>:</p> |
| 5360 <pre class="prettyprint"> |
| 5361 ++NumValuedInsts; |
| 5362 </pre> |
| 5363 <p><strong>Examples</strong>:</p> |
| 5364 <pre class="prettyprint"> |
| 5365 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 5366 48:0| 3: <1, 3> | count 3; |
| 5367 50:4| 3: <2> | @t0 = void; |
| 5368 52:2| 3: <7, 32> | @t1 = i32; |
| 5369 55:4| 3: <21, 0, 0, 1> | @t2 = void (i32); |
| 5370 59:4| 0: <65534> | } |
| 5371 ... |
| 5372 92:0| 1: <65535, 12, 2> | function void @f0(i32 %p0) { |
| 5373 | | // BlockID = 12 |
| 5374 100:0| 3: <1, 1> | blocks 1; |
| 5375 102:4| 1: <65535, 11, 2> | constants { // BlockID = 11 |
| 5376 112:0| 3: <1, 1> | i32: |
| 5377 114:4| 3: <4, 2> | %c0 = i32 1; |
| 5378 117:0| 0: <65534> | } |
| 5379 | | %b0: |
| 5380 120:0| 3: <44, 0, 2, 0, 1> | call void %p0(i32 %c0); |
| 5381 125:4| 3: <10> | ret void; |
| 5382 127:2| 0: <65534> | } |
| 5383 </pre> |
| 5384 <h4 id="indirect-function-call">Indirect Function Call</h4> |
| 5385 <p>The indirect function call calls a function using a value that is an indirect |
| 5386 function address. It is different from the direct function call because we can&#
8217;t |
| 5387 use the type signature of the corresponding literal function address to type |
| 5388 check the construct.</p> |
| 5389 <p><strong>Syntax</strong>:</p> |
| 5390 <pre class="prettyprint"> |
| 5391 %vN = TAIL call RT V (T1 A1, ... , TM AM); <A> |
| 5392 </pre> |
| 5393 <p><strong>Record</strong>:</p> |
| 5394 <pre class="prettyprint"> |
| 5395 AA: <34, CC, RRT, VV, AA1, ... , AAM> |
| 5396 </pre> |
| 5397 <p><strong>Semantics</strong>:</p> |
| 5398 <p>The indirect function call calls a function using a value <code>V</code> that
is an |
| 5399 indirect function address, and is assumed to return type <code>RT</code>. The a
rguments |
| 5400 <code>A1</code> through <code>AM</code> are passed in the order specified. The t
ype of argument <code>AI</code> |
| 5401 must be type <code>TI</code> (for all I, 1 <= I <= N). Flag <code>TAIL</c
ode> is optional. If it is |
| 5402 included, it must be the literal <code>tail</code>.</p> |
| 5403 <p>Each parameter type <code>TI</code> (1 <= I <= M), and return type <cod
e>RT</code>, must either be a |
| 5404 primitive type, or a vector type. If the parameter type is an integer type, it |
| 5405 must either be i32 or i64.</p> |
| 5406 <p>TAIL is encoded into calling convention value <code>CC</code> as follows:</p> |
| 5407 <table border="1" class="docutils"> |
| 5408 <colgroup> |
| 5409 </colgroup> |
| 5410 <thead valign="bottom"> |
| 5411 <tr class="row-odd"><th class="head">TAIL</th> |
| 5412 <th class="head">CC</th> |
| 5413 </tr> |
| 5414 </thead> |
| 5415 <tbody valign="top"> |
| 5416 <tr class="row-even"><td>‘’</td> |
| 5417 <td>0</td> |
| 5418 </tr> |
| 5419 <tr class="row-odd"><td>‘tail’</td> |
| 5420 <td>1</td> |
| 5421 </tr> |
| 5422 </tbody> |
| 5423 </table> |
| 5424 <p>The type signature of the called function is assumed to be:</p> |
| 5425 <pre class="prettyprint"> |
| 5426 RT (T1, ... , TN) |
| 5427 </pre> |
| 5428 <p>It isn’t necessary to define this type in the <a class="reference inter
nal" href="#link-for-types-block-section"><em>types |
| 5429 block</em></a>, since the type is inferred rather than |
| 5430 used.</p> |
| 5431 <p><strong>Constraints</strong>:</p> |
| 5432 <pre class="prettyprint"> |
| 5433 AA == AbbrevIndex(A) & |
| 5434 RRT = TypeID(RT) & |
| 5435 VV = RelativeIndex(V) & |
| 5436 M >= 0 & |
| 5437 AbsoluteIndex(V) >= NumFcnAddresses & |
| 5438 TypeOf(AI) == TI for all I, 1 <= I <= M & |
| 5439 IsFcnArgType(TI) for all I, 1 <= I <= M & |
| 5440 IsFcnArgType(RT) & |
| 5441 N == NumValuedInsts |
| 5442 </pre> |
| 5443 <p><strong>Updates</strong>:</p> |
| 5444 <pre class="prettyprint"> |
| 5445 ++NumValuedInsts; |
| 5446 TypeOf(%vN) = RT; |
| 5447 </pre> |
| 5448 <p><strong>Examples</strong>:</p> |
| 5449 <pre class="prettyprint"> |
| 5450 40:0| 1: <65535, 17, 2> | types { // BlockID = 17 |
| 5451 48:0| 3: <1, 6> | count 6; |
| 5452 50:4| 3: <7, 32> | @t0 = i32; |
| 5453 53:6| 3: <3> | @t1 = float; |
| 5454 55:4| 3: <4> | @t2 = double; |
| 5455 57:2| 3: <21, 0, 0, 0, 1, 2> | @t3 = i32 (i32, float, double)
; |
| 5456 62:6| 3: <21, 0, 0, 1, 2> | @t4 = i32 (float, double); |
| 5457 67:4| 3: <2> | @t5 = void; |
| 5458 69:2| 0: <65534> | } |
| 5459 ... |
| 5460 104:0| 1: <65535, 12, 2> | function |
| 5461 | | i32 |
| 5462 | | @f0(i32 %p0, float %p1, |
| 5463 | | double %p2) { |
| 5464 | | // BlockID = 12 |
| 5465 112:0| 3: <1, 1> | blocks 1; |
| 5466 | | %b0: |
| 5467 114:4| 3: <44, 0, 3, 0, 2, 1> | %v0 = call i32 |
| 5468 | | %p0(float %p1, double %p2); |
| 5469 120:6| 3: <10, 1> | ret i32 %v0; |
| 5470 123:2| 0: <65534> | } |
| 5471 </pre> |
| 5472 <h2 id="memory-blocks-and-alignment"><span id="link-for-memory-blocks-and-alignm
ent-section"></span>Memory Blocks and Alignment</h2> |
| 5473 <p>In general, variable and heap allocated data are represented as byte addressa
ble |
| 5474 memory blocks. Alignment is always a power of 2, and defines an expectation on |
| 5475 the memory address. That is, an alignment is met if the memory address is |
| 5476 (evenly) divisible by the alignment. Note that alignment of 0 is never allowed.<
/p> |
| 5477 <blockquote> |
| 5478 <div>Alignment plays a role at two points:</div></blockquote> |
| 5479 <ul class="small-gap"> |
| 5480 <li>When you create a local/global variable</li> |
| 5481 <li>When you load/store data using a pointer.</li> |
| 5482 </ul> |
| 5483 <p>PNaClAsm allows most types to be placed at any address, and therefore can |
| 5484 have alignment of 1. However, many architectures can load more efficiently |
| 5485 if the data has an alignment that is larger than 1. As such, choosing a larger |
| 5486 alignment can make load/stores more efficient.</p> |
| 5487 <p>On loads and stores, the alignment in the instruction is used to communicate |
| 5488 what assumptions the <a class="reference internal" href="/native-client/overview
.html#link-for-pnacl-translator"><em>PNaCl translator</em></a> can |
| 5489 make when choosing the appropriate machine instructions. If the alignment is 1, |
| 5490 it can’t assume anything about the memory address used by the instruction.
When |
| 5491 the alignment is greater than one, it can use that information to potentially |
| 5492 chose a more efficient sequence of instructions to do the load/store.</p> |
| 5493 <p>When laying out data within a variable, one also considers alignment. The rea
son |
| 5494 for this is that if you want an address to be aligned, within the bytes defining |
| 5495 the variable, you must choose an alignment for the variable that guarantees that |
| 5496 alignment.</p> |
| 5497 <p>In PNaClAsm, the valid load/store alignments are:</p> |
| 5498 <table border="1" class="docutils"> |
| 5499 <colgroup> |
| 5500 </colgroup> |
| 5501 <thead valign="bottom"> |
| 5502 <tr class="row-odd"><th class="head">Type</th> |
| 5503 <th class="head">Alignment</th> |
| 5504 </tr> |
| 5505 </thead> |
| 5506 <tbody valign="top"> |
| 5507 <tr class="row-even"><td>i1</td> |
| 5508 <td>1</td> |
| 5509 </tr> |
| 5510 <tr class="row-odd"><td>i8</td> |
| 5511 <td>1</td> |
| 5512 </tr> |
| 5513 <tr class="row-even"><td>i16</td> |
| 5514 <td>1</td> |
| 5515 </tr> |
| 5516 <tr class="row-odd"><td>i32</td> |
| 5517 <td>1</td> |
| 5518 </tr> |
| 5519 <tr class="row-even"><td>i64</td> |
| 5520 <td>1</td> |
| 5521 </tr> |
| 5522 <tr class="row-odd"><td>Float</td> |
| 5523 <td>1, 4</td> |
| 5524 </tr> |
| 5525 <tr class="row-even"><td>Double</td> |
| 5526 <td>1, 8</td> |
| 5527 </tr> |
| 5528 <tr class="row-odd"><td><4 x i1></td> |
| 5529 <td>not applicable</td> |
| 5530 </tr> |
| 5531 <tr class="row-even"><td><8 x i1></td> |
| 5532 <td>not applicable</td> |
| 5533 </tr> |
| 5534 <tr class="row-odd"><td><16 x i1></td> |
| 5535 <td>not applicable</td> |
| 5536 </tr> |
| 5537 <tr class="row-even"><td><16 x i8></td> |
| 5538 <td>1</td> |
| 5539 </tr> |
| 5540 <tr class="row-odd"><td><8 x i16></td> |
| 5541 <td>2</td> |
| 5542 </tr> |
| 5543 <tr class="row-even"><td><4 x i32></td> |
| 5544 <td>4</td> |
| 5545 </tr> |
| 5546 <tr class="row-odd"><td><4 x float></td> |
| 5547 <td>4</td> |
| 5548 </tr> |
| 5549 </tbody> |
| 5550 </table> |
| 5551 <p>Note that only vectors do not have an alignment value of 1. Hence, they can&#
8217;t be |
| 5552 placed at an arbitrary memory address. Also, since vectors on <code>i1</code> ca
n’t be |
| 5553 loaded/stored, the alignment is not applicable for these types.</p> |
| 5554 <h2 id="intrinsic-functions"><span id="link-for-intrinsic-functions-section"></s
pan>Intrinsic Functions</h2> |
| 5555 <p>Intrinsic functions are special in PNaClAsm. They are implemented as speciall
y |
| 5556 named (external) function calls. The purpose of these intrinsic functions is to |
| 5557 extend the PNaClAsm instruction set with additional functionality that is |
| 5558 architecture specific. Hence, they either can’t be implemented within PNaC
lAsm, |
| 5559 or a non-architecture specific implementation may be too slow on some |
| 5560 architectures. In such cases, the <a class="reference internal" href="/native-cl
ient/overview.html#link-for-pnacl-translator"><em>PNaCl |
| 5561 translator</em></a> must fill in the corresponding |
| 5562 implementation, since only it knows the architecture it is compiling down to.</p
> |
| 5563 <p>Examples of intrinsic function calls are for concurrent operations, atomic |
| 5564 operations, bulk memory moves, thread pointer operations, and long jumps.</p> |
| 5565 <p>It should be noted that calls to intrinsic functions do not have the same |
| 5566 calling type constraints as ordinary functions. That is, an intrisic can use |
| 5567 any integer type for arguments/results, unlike ordinary functions (which |
| 5568 restrict integer types to <code>i32</code> and <code>i64</code>).</p> |
| 5569 <p>See the <a class="reference internal" href="/native-client/reference/pnacl-bi
tcode-abi.html"><em>PNaCl bitcode reference manual</em></a> for the full |
| 5570 set of intrinsic functions allowed. Note that in PNaClAsm, all pointer types to |
| 5571 an (LLVM) intrinsic function is converted to type i32.</p> |
| 5572 <h2 id="support-functions"><span id="link-for-support-functions-section"></span>
Support Functions</h2> |
| 5573 <p>Defines functions used to convert syntactic representation to values in the |
| 5574 corresponding record.</p> |
| 5575 <h3 id="signrotate">SignRotate</h3> |
| 5576 <p>The SignRotate function encodes a signed integer in an easily compressible |
| 5577 form. This is done by rotating the sign bit to the rightmost bit, rather than |
| 5578 the leftmost bit. By doing this rotation, both small positive and negative |
| 5579 integers are small (unsigned) integers. Therefore, all small integers can be |
| 5580 encoded as a small (unsigned) integers.</p> |
| 5581 <p>The definition of SignRotate(N) is:</p> |
| 5582 <table border="1" class="docutils"> |
| 5583 <colgroup> |
| 5584 </colgroup> |
| 5585 <thead valign="bottom"> |
| 5586 <tr class="row-odd"><th class="head">Argument</th> |
| 5587 <th class="head">Value</th> |
| 5588 <th class="head">Condition</th> |
| 5589 </tr> |
| 5590 </thead> |
| 5591 <tbody valign="top"> |
| 5592 <tr class="row-even"><td>N</td> |
| 5593 <td>abs(N)<<1</td> |
| 5594 <td>N >= 0</td> |
| 5595 </tr> |
| 5596 <tr class="row-odd"><td>N</td> |
| 5597 <td>abs(N)<<1 + 1</td> |
| 5598 <td>N < 0</td> |
| 5599 </tr> |
| 5600 </tbody> |
| 5601 </table> |
| 5602 <h3 id="absoluteindex"><span id="link-for-absolute-index-section"></span>Absolut
eIndex</h3> |
| 5603 <p>Bitcode IDs of the forms <code>@fN</code>, <code>@gN</code>, <code>%p
N</code>, <code>%cN</code>, and <code>%vN</code>, are |
| 5604 combined into a single index space. This can be done because of the ordering |
| 5605 imposed by PNaClAsm. All function address bitcode IDs must be defined before any |
| 5606 of the other forms of bitcode IDs. All global address bitcode IDs must be |
| 5607 defined before any local bitcode IDs. Within a function block, the parameter |
| 5608 bitcode IDs must be defined before constant IDs, and constant IDs must be |
| 5609 defined before instruction value IDs.</p> |
| 5610 <p>Hence, within a function block, it is safe to refer to all of these |
| 5611 bitcode IDs using a single <em>absolute</em> index. The absolute index for |
| 5612 each kind of bitcode ID is computed as follows:</p> |
| 5613 <table border="1" class="docutils"> |
| 5614 <colgroup> |
| 5615 </colgroup> |
| 5616 <thead valign="bottom"> |
| 5617 <tr class="row-odd"><th class="head">Bitcode ID</th> |
| 5618 <th class="head">AbsoluteIndex</th> |
| 5619 </tr> |
| 5620 </thead> |
| 5621 <tbody valign="top"> |
| 5622 <tr class="row-even"><td>@tN</td> |
| 5623 <td>N</td> |
| 5624 </tr> |
| 5625 <tr class="row-odd"><td>@fN</td> |
| 5626 <td>N</td> |
| 5627 </tr> |
| 5628 <tr class="row-even"><td>@gN</td> |
| 5629 <td>N + NumFcnAddresses</td> |
| 5630 </tr> |
| 5631 <tr class="row-odd"><td>@pN</td> |
| 5632 <td>N + NumFcnAddresses + NumGlobalAddresses</td> |
| 5633 </tr> |
| 5634 <tr class="row-even"><td>@cN</td> |
| 5635 <td>N + NumFcnAddresses + NumGlobalAddresses + NumParams</td> |
| 5636 </tr> |
| 5637 <tr class="row-odd"><td>@vN</td> |
| 5638 <td>N + NumFcnAddresses + NumGlobalAddresses + NumParams + NumFcnConsts</td> |
| 5639 </tr> |
| 5640 </tbody> |
| 5641 </table> |
| 5642 <h3 id="relativeindex"><span id="link-for-relative-index"></span>RelativeIndex</
h3> |
| 5643 <p>Relative indices are used to refer to values within instructions of a functio
n. |
| 5644 The relative index of an ID is always defined in terms of the index associated |
| 5645 with the next value generating instruction. It is defined as follows:</p> |
| 5646 <pre class="prettyprint"> |
| 5647 RelativeIndex(J) = AbsoluteIndex(%vN) - AbsoluteIndex(J) |
| 5648 </pre> |
| 5649 <p>where:</p> |
| 5650 <pre class="prettyprint"> |
| 5651 N = NumValuedInsts |
| 5652 </pre> |
| 5653 <h3 id="abbrevindex">AbbrevIndex</h3> |
| 5654 <p>This function converts user-defined abbreviation indices to the corresponding |
| 5655 internal abbreviation index saved in the bitcode file. It adds 4 to its |
| 5656 argument, since there are 4 predefined internal abbreviation indices (0, 1, 2, |
| 5657 and 3).</p> |
| 5658 <table border="1" class="docutils"> |
| 5659 <colgroup> |
| 5660 </colgroup> |
| 5661 <thead valign="bottom"> |
| 5662 <tr class="row-odd"><th class="head">N</th> |
| 5663 <th class="head">AbbrevIndex(N)</th> |
| 5664 </tr> |
| 5665 </thead> |
| 5666 <tbody valign="top"> |
| 5667 <tr class="row-even"><td>undefined</td> |
| 5668 <td>3</td> |
| 5669 </tr> |
| 5670 <tr class="row-odd"><td>%aA</td> |
| 5671 <td>A + 4</td> |
| 5672 </tr> |
| 5673 <tr class="row-even"><td>@aA</td> |
| 5674 <td>A + 4</td> |
| 5675 </tr> |
| 5676 </tbody> |
| 5677 </table> |
| 5678 <h3 id="log2">Log2</h3> |
| 5679 <p>This is the 32-bit log2 value of its argument.</p> |
| 5680 <h3 id="bitsizeof">BitSizeOf</h3> |
| 5681 <p>Returns the number of bits needed to represent its argument (a type).</p> |
| 5682 <table border="1" class="docutils"> |
| 5683 <colgroup> |
| 5684 </colgroup> |
| 5685 <thead valign="bottom"> |
| 5686 <tr class="row-odd"><th class="head">T</th> |
| 5687 <th class="head">BitSizeOf</th> |
| 5688 </tr> |
| 5689 </thead> |
| 5690 <tbody valign="top"> |
| 5691 <tr class="row-even"><td>i1</td> |
| 5692 <td>1</td> |
| 5693 </tr> |
| 5694 <tr class="row-odd"><td>i8</td> |
| 5695 <td>8</td> |
| 5696 </tr> |
| 5697 <tr class="row-even"><td>i16</td> |
| 5698 <td>16</td> |
| 5699 </tr> |
| 5700 <tr class="row-odd"><td>i32</td> |
| 5701 <td>32</td> |
| 5702 </tr> |
| 5703 <tr class="row-even"><td>i64</td> |
| 5704 <td>64</td> |
| 5705 </tr> |
| 5706 <tr class="row-odd"><td>float</td> |
| 5707 <td>32</td> |
| 5708 </tr> |
| 5709 <tr class="row-even"><td>double</td> |
| 5710 <td>64</td> |
| 5711 </tr> |
| 5712 <tr class="row-odd"><td><N X T></td> |
| 5713 <td>N * BitSizeOf(T)</td> |
| 5714 </tr> |
| 5715 </tbody> |
| 5716 </table> |
| 5717 <h3 id="underlyingtype">UnderlyingType</h3> |
| 5718 <p>Returns the primitive type of the type construct. For primitive types, the |
| 5719 <em>UnderlyingType</em> is itself. For vector types, the base type of the vector
is the |
| 5720 underlying type.</p> |
| 5721 <h3 id="underlyingcount">UnderlyingCount</h3> |
| 5722 <p>Returns the size of the vector if given a vector, and 0 for primitive types. |
| 5723 Note that this function is used to check if two vectors are of the same size. |
| 5724 It is also used to test if two types are either primitive (i.e. UnderlyingCount |
| 5725 returns 0 for both types) or are vectors of the same size (i.e. UnderlyingCount |
| 5726 returns the same non-zero value).</p> |
| 5727 <h3 id="isinteger">IsInteger</h3> |
| 5728 <p>Returns true if the argument is in {i1, i8, i16, i32, i64}.</p> |
| 5729 <h3 id="isfloat">IsFloat</h3> |
| 5730 <p>Returns true if the argument is in {<code>float</code>, <code>double</code>}.
</p> |
| 5731 <h3 id="isvector">IsVector</h3> |
| 5732 <p>Returns true if the argument is a vector type.</p> |
| 5733 <h3 id="isprimitive">IsPrimitive</h3> |
| 5734 <p>Returns true if the argument is a primitive type. That is:</p> |
| 5735 <pre class="prettyprint"> |
| 5736 IsPrimitive(T) == IsInteger(T) or IsFloat(T) |
| 5737 </pre> |
| 5738 <h3 id="isfcnargtype">IsFcnArgType</h3> |
| 5739 <p>Returns true if the argument is a primitive type or a vector type. Further, |
| 5740 if it is an integer type, it must be i32 or i64. That is:</p> |
| 5741 <pre class="prettyprint"> |
| 5742 IsFcnArgType(T) = (IsInteger(T) and (i32 = BitSizeOf(T) |
| 5743 or i64 == BitSizeOf(T))) |
| 5744 or IsFloat(T) or IsVector(T) |
| 5745 </pre> |
| 5746 <h2 id="abbreviations"><span id="link-for-abbreviations-section"></span>Abbrevia
tions</h2> |
| 5747 <p>Abbreviations are used to convert PNaCl records to a sequence of bits. PNaCl |
| 5748 uses the same strategy as <a class="reference external" href="http://llvm.org/do
cs/BitCodeFormat.html">LLVM’s bitcode file format</a>. See that document
for more |
| 5749 details.</p> |
| 5750 <p>It should be noted that we replace LLVM’s header (called the <em>Bitcod
e Wrapper |
| 5751 Format</em>) with the bytes of the <a class="reference internal" href="#link-for
-header-record-section"><em>PNaCl record |
| 5752 header</em></a>. In addition, PNaCl bitcode files do |
| 5753 not allow <em>blob</em> abbreviation.</p> |
| 5754 <h3 id="abbreviations-block"><span id="link-for-abbreviations-block-section"></s
pan>Abbreviations Block</h3> |
| 5755 <p>The abbreviations block is the first block in the module build. The |
| 5756 block is divided into sections. Each section is a sequence of records. Each |
| 5757 record in the sequence defines a user-defined abbreviation. Each section |
| 5758 defines abbreviations that can be applied to all (succeeding) blocks of a |
| 5759 particular kind. These abbreviations are denoted by the (global) ID of the form |
| 5760 <em>@aN</em>.</p> |
| 5761 <p>In terms of <a class="reference external" href="http://llvm.org/docs/BitCodeF
ormat.html">LLVM’s bitcode file format</a>, the abbreviations block is cal
led a |
| 5762 <em>BLOCKINFO</em> block. Records <em>SETBID</em> and <em>DEFINE_ABBREV</em> are
the only records |
| 5763 allowed in PNaCl’s abbreviation block (i.e. it doesn’t allow <em>BLO
CKNAME</em> and |
| 5764 <em>SETRECORDNAME</em> records).</p> |
| 5765 <h3 id="todo">TODO</h3> |
| 5766 <p>Extend this document to describe PNaCl’s bitcode bit sequencer |
| 5767 without requiring the reader to refer to <a class="reference external" href="htt
p://llvm.org/docs/BitCodeFormat.html">LLVM’s bitcode file |
| 5768 format</a>.</p> |
| 5769 </section> |
| 5770 |
| 5771 {{/partials.standard_nacl_article}} |
| OLD | NEW |
|---|
Chromium Code Reviews
Issue 725333002:
Initial draft of PNaCl bitcode files. (Closed)
Base URL: https://chromium.googlesource.com/chromium/src.git@master