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