native_client_sdk/doc_generated/reference/pnacl-bitcode-manual.html - Issue 725333002: Initial draft of PNaCl bitcode files.

Unified Diff: native_client_sdk/doc_generated/reference/pnacl-bitcode-manual.html

Issue 725333002: Initial draft of PNaCl bitcode files. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: Fix additional changes suggested by Jim. Created 6 years, 1 month ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View side-by-side diff with in-line comments

Download patch

« no previous file with comments | « native_client_sdk/doc_generated/overview.html ('k') | native_client_sdk/doc_generated/reference/pnacl-c-cpp-language-support.html » ('j') | native_client_sdk/src/doc/devguide/devcycle/building.rst » ('J')
Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

Index: native_client_sdk/doc_generated/reference/pnacl-bitcode-manual.html

diff --git a/native_client_sdk/doc_generated/reference/pnacl-bitcode-manual.html b/native_client_sdk/doc_generated/reference/pnacl-bitcode-manual.html

new file mode 100644

index 0000000000000000000000000000000000000000..485fc68a36443aa7510916a28bceae1b6304ad45

--- /dev/null

+++ b/native_client_sdk/doc_generated/reference/pnacl-bitcode-manual.html

@@ -0,0 +1,5778 @@

+{{+bindTo:partials.standard_nacl_article}}

+<section id="contents-of-pnacl-bitcode-files">

+<h1 id="contents-of-pnacl-bitcode-files">Contents Of PNaCl Bitcode Files</h1>

+<div class="contents local" id="contents" style="display: none">

+<ul class="small-gap">

+<li><a class="reference internal" href="#introduction" id="id6">Introduction</a></li>

+<li><a class="reference internal" href="#data-model" id="id7">Data Model</a></li>

+<li><a class="reference internal" href="#pnacl-blocks" id="id8">PNaCl Blocks</a></li>

+<li><a class="reference internal" href="#pnacl-records" id="id9">PNaCl Records</a></li>

+<li><a class="reference internal" href="#default-abbreviations" id="id10">Default Abbreviations</a></li>

+<li><a class="reference internal" href="#pnacl-identifiers" id="id11">PNaCl Identifiers</a></li>

+<li><a class="reference internal" href="#conventions-for-describing-records" id="id12">Conventions For Describing Records</a></li>

+<li><a class="reference internal" href="#factorial-example" id="id13">Factorial Example</a></li>

+<li><a class="reference internal" href="#road-map" id="id14">Road Map</a></li>

+<li><a class="reference internal" href="#global-state" id="id15">Global State</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#typing-functions" id="id16">Typing Functions</a></li>

+<li><a class="reference internal" href="#link-to-id-counters" id="id17">ID Counters</a></li>

+<li><a class="reference internal" href="#size-variables" id="id18">Size Variables</a></li>

+<li><a class="reference internal" href="#other-variables" id="id19">Other Variables</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#global-records" id="id20">Global Records</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#header-record" id="id21">Header Record</a></li>

+<li><a class="reference internal" href="#enter-block-record" id="id22">Enter Block Record</a></li>

+<li><a class="reference internal" href="#exit-block-record" id="id23">Exit Block Record</a></li>

+<li><a class="reference internal" href="#abbreviation-record" id="id24">Abbreviation Record</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#types-block" id="id25">Types Block</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#count-record" id="id26">Count Record</a></li>

+<li><a class="reference internal" href="#void-type" id="id27">Void Type</a></li>

+<li><a class="reference internal" href="#integer-types" id="id28">Integer Types</a></li>

+<li><a class="reference internal" href="#bit-floating-point-type" id="id29">32-Bit Floating Point Type</a></li>

+<li><a class="reference internal" href="#id1" id="id30">64-bit Floating Point Type</a></li>

+<li><a class="reference internal" href="#vector-types" id="id31">Vector Types</a></li>

+<li><a class="reference internal" href="#function-type" id="id32">Function Type</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#globals-block" id="id33">Globals Block</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#link-for-globals-count-record" id="id34">Count Record</a></li>

+<li><a class="reference internal" href="#global-variable-addresses" id="id35">Global Variable Addresses</a></li>

+<li><a class="reference internal" href="#global-constant-addresses" id="id36">Global Constant Addresses</a></li>

+<li><a class="reference internal" href="#zerofill-initializer" id="id37">Zerofill Initializer</a></li>

+<li><a class="reference internal" href="#data-initializer" id="id38">Data Initializer</a></li>

+<li><a class="reference internal" href="#relocation-initializer" id="id39">Relocation Initializer</a></li>

+<li><a class="reference internal" href="#subfield-relocation-initializer" id="id40">Subfield Relocation Initializer</a></li>

+<li><a class="reference internal" href="#compound-initializer" id="id41">Compound Initializer</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#valuesymtab-block" id="id42">Valuesymtab Block</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#entry-record" id="id43">Entry Record</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#module-block" id="id44">Module Block</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#version-record" id="id45">Version Record</a></li>

+<li><a class="reference internal" href="#function-address" id="id46">Function Address</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#constants-blocks" id="id47">Constants Blocks</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#set-type-record" id="id48">Set Type Record</a></li>

+<li><a class="reference internal" href="#undefined-literal" id="id49">Undefined Literal</a></li>

+<li><a class="reference internal" href="#integer-literal" id="id50">Integer Literal</a></li>

+<li><a class="reference internal" href="#floating-point-literal" id="id51">Floating Point Literal</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#function-blocks" id="id52">Function Blocks</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#function-enter" id="id53">Function Enter</a></li>

+<li><a class="reference internal" href="#link-for-basic-blocks-count" id="id54">Count Record</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#terminator-instructions" id="id55">Terminator Instructions</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#return-void-instruction" id="id56">Return Void Instruction</a></li>

+<li><a class="reference internal" href="#return-value-instruction" id="id57">Return Value Instruction</a></li>

+<li><a class="reference internal" href="#unconditional-branch-instruction" id="id58">Unconditional Branch Instruction</a></li>

+<li><a class="reference internal" href="#conditional-branch-instruction" id="id59">Conditional Branch Instruction</a></li>

+<li><a class="reference internal" href="#unreachable" id="id60">Unreachable</a></li>

+<li><a class="reference internal" href="#switch-instruction" id="id61">Switch Instruction</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#integer-binary-instructions" id="id62">Integer Binary Instructions</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#integer-add" id="id63">Integer Add</a></li>

+<li><a class="reference internal" href="#integer-subtract" id="id64">Integer Subtract</a></li>

+<li><a class="reference internal" href="#integer-multiply" id="id65">Integer Multiply</a></li>

+<li><a class="reference internal" href="#signed-integer-divide" id="id66">Signed Integer Divide</a></li>

+<li><a class="reference internal" href="#unsigned-integer-divide" id="id67">Unsigned Integer Divide</a></li>

+<li><a class="reference internal" href="#signed-integer-remainder" id="id68">Signed Integer Remainder</a></li>

+<li><a class="reference internal" href="#unsigned-integer-remainder-instruction" id="id69">Unsigned Integer Remainder Instruction</a></li>

+<li><a class="reference internal" href="#shift-left" id="id70">Shift Left</a></li>

+<li><a class="reference internal" href="#logical-shift-right" id="id71">Logical Shift Right</a></li>

+<li><a class="reference internal" href="#arithmetic-shift-right" id="id72">Arithmetic Shift Right</a></li>

+<li><a class="reference internal" href="#logical-and" id="id73">Logical And</a></li>

+<li><a class="reference internal" href="#logical-or" id="id74">Logical Or</a></li>

+<li><a class="reference internal" href="#logical-xor" id="id75">Logical Xor</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#floating-point-binary-instructions" id="id76">Floating Point Binary Instructions</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#floating-point-add" id="id77">Floating Point Add</a></li>

+<li><a class="reference internal" href="#floating-point-subtract" id="id78">Floating Point Subtract</a></li>

+<li><a class="reference internal" href="#floating-point-multiply" id="id79">Floating Point Multiply</a></li>

+<li><a class="reference internal" href="#floating-point-divide" id="id80">Floating Point Divide</a></li>

+<li><a class="reference internal" href="#floating-point-remainder" id="id81">Floating Point Remainder</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#memory-creation-and-access-instructions" id="id82">Memory Creation and Access Instructions</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#alloca-instruction" id="id83">Alloca Instruction</a></li>

+<li><a class="reference internal" href="#load-instruction" id="id84">Load Instruction</a></li>

+<li><a class="reference internal" href="#store-instruction" id="id85">Store Instruction</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#conversion-instructions" id="id86">Conversion Instructions</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#integer-truncating-instruction" id="id87">Integer Truncating Instruction</a></li>

+<li><a class="reference internal" href="#floating-point-truncating-instruction" id="id88">Floating Point Truncating Instruction</a></li>

+<li><a class="reference internal" href="#zero-extending-instruction" id="id89">Zero Extending Instruction</a></li>

+<li><a class="reference internal" href="#sign-extending-instruction" id="id90">Sign Extending Instruction</a></li>

+<li><a class="reference internal" href="#floating-point-extending-instruction" id="id91">Floating Point Extending Instruction</a></li>

+<li><a class="reference internal" href="#floating-point-to-unsigned-integer-instruction" id="id92">Floating Point to Unsigned Integer Instruction</a></li>

+<li><a class="reference internal" href="#floating-point-to-signed-integer-instruction" id="id93">Floating Point to Signed Integer Instruction</a></li>

+<li><a class="reference internal" href="#unsigned-integer-to-floating-point-instruction" id="id94">Unsigned Integer to Floating Point Instruction</a></li>

+<li><a class="reference internal" href="#signed-integer-to-floating-point-instruction" id="id95">Signed Integer to Floating Point Instruction</a></li>

+<li><a class="reference internal" href="#bitcast-instruction" id="id96">Bitcast Instruction</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#comparison-instructions" id="id97">Comparison Instructions</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#integer-comparison-instructions" id="id98">Integer Comparison Instructions</a></li>

+<li><a class="reference internal" href="#floating-point-comparison-instructions" id="id99">Floating Point Comparison Instructions</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#vector-instructions" id="id100">Vector Instructions</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#insert-element-instruction" id="id101">Insert Element Instruction</a></li>

+<li><a class="reference internal" href="#extract-element-instruction" id="id102">Extract Element Instruction</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#other-instructions" id="id103">Other Instructions</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#forward-type-declaration" id="id104">Forward Type Declaration</a></li>

+<li><a class="reference internal" href="#phi-instruction" id="id105">Phi Instruction</a></li>

+<li><a class="reference internal" href="#select-instruction" id="id106">Select Instruction</a></li>

+<li><a class="reference internal" href="#call-instructions" id="id107">Call Instructions</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#direct-procedure-call" id="id108">Direct Procedure Call</a></li>

+<li><a class="reference internal" href="#direct-function-call" id="id109">Direct Function Call</a></li>

+<li><a class="reference internal" href="#indirect-procedure-call" id="id110">Indirect Procedure Call</a></li>

+<li><a class="reference internal" href="#indirect-function-call" id="id111">Indirect Function Call</a></li>

+</ul>

+</li>

+</ul>

+</li>

+<li><a class="reference internal" href="#memory-blocks-and-alignment" id="id112">Memory Blocks and Alignment</a></li>

+<li><a class="reference internal" href="#intrinsic-functions" id="id113">Intrinsic Functions</a></li>

+<li><a class="reference internal" href="#support-functions" id="id114">Support Functions</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#signrotate" id="id115">SignRotate</a></li>

+<li><a class="reference internal" href="#absoluteindex" id="id116">AbsoluteIndex</a></li>

+<li><a class="reference internal" href="#relativeindex" id="id117">RelativeIndex</a></li>

+<li><a class="reference internal" href="#abbrevindex" id="id118">AbbrevIndex</a></li>

+<li><a class="reference internal" href="#log2" id="id119">Log2</a></li>

+<li><a class="reference internal" href="#bitsizeof" id="id120">BitSizeOf</a></li>

+<li><a class="reference internal" href="#underlyingtype" id="id121">UnderlyingType</a></li>

+<li><a class="reference internal" href="#underlyingcount" id="id122">UnderlyingCount</a></li>

+<li><a class="reference internal" href="#isinteger" id="id123">IsInteger</a></li>

+<li><a class="reference internal" href="#isfloat" id="id124">IsFloat</a></li>

+<li><a class="reference internal" href="#isvector" id="id125">IsVector</a></li>

+<li><a class="reference internal" href="#isprimitive" id="id126">IsPrimitive</a></li>

+<li><a class="reference internal" href="#isfcnargtype" id="id127">IsFcnArgType</a></li>

+</ul>

+</li>

+<li><a class="reference internal" href="#abbreviations" id="id128">Abbreviations</a>

+<ul class="small-gap">

+<li><a class="reference internal" href="#abbreviations-block" id="id129">Abbreviations Block</a></li>

+<li><a class="reference internal" href="#todo" id="id130">TODO</a></li>

+</ul>

+</li>

+</ul>

+</div><h2 id="introduction">Introduction</h2>

+This document is a reference manual for the contents of PNaCl bitcode files. We

+define bitcode files via three layers. The first layer is presented using

+assembly language PNaClAsm, and defines the textual form of the bitcode

+file. The textual form is then lowered to a sequence of <a class="reference internal" href="#link-for-pnacl-records">PNaCl

+records</a>. The final layer applies abbreviations that

+convert each PNaCl record into a corresponding sequence of bits.

+<img alt="/native-client/images/PNaClBitcodeFlow.png" src="/native-client/images/PNaClBitcodeFlow.png" />

+PNaClAsm uses a static single assignment (SSA) based representation that

+requires generated results to have a single (assignment) source.

+PNaClAsm focuses on the semantic content of the file, not the bit-encoding of

+that content. However, it does provide annotations that allow one to specify how

+the <a class="reference internal" href="#link-for-abbreviations-section">abbreviations</a> are used to convert

+PNaCl records into the sequence of bits.

+Each construct in PNaClAsm defines a corresponding <a class="reference internal" href="#link-for-pnacl-records">PNaCl

+record</a>. A PNaCl bitcode file is simply a sequence of

+PNaCl records. The goal of PNaClAsm is to make records easier to read, and not

+to define a high-level user programming language.

+PNaCl records are an abstract encoding of structured data, similar to XML. Like

+XML, A PNaCl record has a notion of a tag (i.e. the first element in a record,

+called a code). PNaCl records can be nested. Nesting is defined by a

+corresponding <a class="reference internal" href="#link-for-enter-block-record-section">enter</a> and

+<a class="reference internal" href="#link-for-exit-block-record-section">exit</a> block record.

+These block records must be used like balanced parentheses to define the block

+structure that is imposed on top of records. Each exit record must be preceded

+by a corresponding enter record. Blocks can be nested by nesting enter/exit

+records appropriately.

+The PNaCl bitcode writer takes the sequence of records, defined by a PNaClAsm

+program, and converts each record into a (variable-length) sequence of bits. The

+output of each bit sequence is appended together. The resulting generated

+sequence of bits is the contents of the PNaCl bitcode file.

+For every kind of record, there is a method for converting records into bit

+sequences. These methods correspond to a notion of

+<a class="reference internal" href="#link-for-abbreviations-section">abbreviations</a>. Each abbreviation defines

+a specific bit sequence conversion to be applied.

+Abbreviations can be user-defined, but there are also predefined defaults. All

+user-specified abbreviations are included in the generated bitcode

+file. Predefined defaults are not.

+Each abbreviation defines how a record is converted to a bit sequence. The

+<a class="reference internal" href="/native-client/overview.html#link-for-pnacl-translator">PNaCl translator</a> uses these abbreviations

+to convert the bit sequence back to the corresponding sequence of PNaCl records.

+As a result, all records have an abbreviation (user or default) associated with

+them.

+Conceptually, abbreviations are used to define how to pack the contents of

+records into bit sequences. The main reason for defining abbreviations is to

+save space. The default abbreviations are simplistic and are intended to handle

+all possible records. The default abbreviations do not really worry about being

+efficient, in terms of the number of bits generated.

+By separating the concepts of PNaCl records and abbreviations, the notion of

+data compression is cleanly separated from semantic content. This allows

+different use cases to decide how much effort should be spent on compressing

+records.

+For a JIT compiler that produces bitcode, little (if any) compression should be

+applied. In fact, the API to the JIT may just be the records themselves. The

+goal of a JIT is to perform the final translation to machine code as quickly as

+possible.

+On the other hand, when delivering across the web, one may want to compress the

+sequence of bits considerably, to reduce costs in delivering web pages. Note

+that <a class="reference internal" href="/native-client/devguide/devcycle/building.html#pnacl-compress">pnacl-compress</a> is provided as part of the SDK to do

+this job.

+<h2 id="data-model">Data Model</h2>

+The data model for PNaCl bitcode is fixed at little-endian ILP32: pointers are

+32 bits in size. 64-bit integer types are also supported natively via the i64

+type (for example, a front-end can generate these from the C/C++ type <code>long

+long</code>).

+Integers are assumed to be modeled using two’s complement. Floating point

+support is fixed at <a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html#c-cpp-floating-point">IEEE 754</a> 32-bit and 64-bit

+values (float and double, respectively).

+<h2 id="pnacl-blocks">PNaCl Blocks</h2>

+Blocks are used to organize records in the bitcode file. The kinds of blocks

+defined in PNaClAsm are:

+<dl class="docutils">

+<dt>Module block</dt>

+<dd>A top-level block defining the program. The <a class="reference internal" href="#link-for-module-block">module

+block</a> defines global information used by the program,

+followed by function blocks defining the implementation of functions within

+the program. All other blocks (listed below) must appear within a module

+block.</dd>

+<dt>Types block</dt>

+<dd>The <a class="reference internal" href="#link-for-types-block-section">types block</a> defines the set of types

+used by the program. All types used in the program must be defined in the

+types block. These types consist of primitive types as well as high level

+constructs such as vectors and function signatures.</dd>

+<dt>Globals block</dt>

+<dd>The <a class="reference internal" href="#link-for-globals-block-section">globals block</a> defines the set of

+global addresses of global variables and constants used by the program. It

+also defines how each global (associated with the global address) is

+initialized.</dd>

+<dt>Valuesymtab block</dt>

+<dd>The <a class="reference internal" href="#link-for-valuesymtab-block-section">valuesymtab block</a> defines

+textual names for external function addresses.</dd>

+<dt>Function block</dt>

+<dd>Each function (implemented) in a program has its own <a class="reference internal" href="#link-for-function-blocks-section">function

+block</a> that defines the implementation of

+the corresponding function.</dd>

+<dt>Constants block</dt>

+<dd>Each implemented function that uses constants in its instructions defines a

+<a class="reference internal" href="#link-for-constants-block-section">constants block</a>. Constants blocks

+appear within the corresponding function block of the implemented function.</dd>

+<dt>Abbreviations block</dt>

+<dd>Defines global abbreviations that are used to compress PNaCl records. The

+<a class="reference internal" href="#link-for-abbreviations-block-section">abbreviations block</a> is segmented

+into multiple sections, one section for each kind of block. This block appears

+at the beginning of the module block.</dd>

+</dl>

+This section is only intended as a high-level discussion of blocks. Later

+sections will dive more deeply into the constraints on how blocks must be laid

+out. This section only presents the overall concepts of what kinds of data are

+stored in each of the blocks.

+A PNaCl program consists of a <a class="reference internal" href="#link-for-header-record-section">header

+record</a> and a <a class="reference internal" href="#link-for-module-block">module

+block</a>. The header record defines a sequence of bytes

+uniquely identifying the file as a bitcode file. The module block defines the

+program to run.

+Each block, within a bitcode file, defines values. These values are associated

+with IDs. Each type of block defines different kinds of IDs. The

+<a class="reference internal" href="#link-for-module-block">module</a>,

+<a class="reference internal" href="#link-for-types-block-section">types</a>,

+<a class="reference internal" href="#link-for-globals-block-section">globals</a>, and

+<a class="reference internal" href="#link-for-abbreviations-block-section">abbreviations</a> blocks define global

+identifiers, and only a single instance can appear. The

+<a class="reference internal" href="#link-for-function-blocks-section">function</a> and

+<a class="reference internal" href="#link-for-constants-block-section">constant</a> blocks define local

+identifiers, and can have multiple instances (one for each implemented

+function).

+The only records in the module block that define values, are <a class="reference internal" href="#link-for-function-address-section">function

+address</a> records. Each function address

+record defines a different function address, and the <a class="reference internal" href="#link-for-function-type">type

+signature</a> associated with that function address.

+Each <a class="reference internal" href="#link-for-function-blocks-section">function block</a> defines the

+implementation of a single function. Each function block defines the

+intermediate representation of the function, consisting of basic blocks and

+instructions. If constants are used within instructions, they are defined in a

+<a class="reference internal" href="#link-for-constants-block-section">constants block</a>, nested within the

+corresponding function block.

+All function blocks are associated with a corresponding function address. This

+association is positional rather than explicit. That is, the Nth function block

+in a module block corresponds to the Nth

+<a class="reference internal" href="#link-for-function-address-section">defining</a> (rather than declared)

+function address record in the module block.

+Hence, within a function block, there is no explicit reference to the function

+address the block defines. For readability, PNaClAsm uses the corresponding

+function signature, associated with the corresponding function address record,

+even though that data does not appear in the corresponding records.

+<h2 id="pnacl-records">PNaCl Records</h2>

+A PNaCl record is a non-empty sequence of unsigned, 64-bit, integers. A record

+is identified by the record code, which is the first element in the

+sequence. Record codes are unique within a specific kind of block, but are not

+necessarily unique across different kinds of blocks. The record code acts as the

+variant discriminator (i.e. tag) within a block, to identify what kind of record

+it is.

+Record codes that are local to a specific kind of block are small values

+(starting from zero). In an ideal world, they would be a consecutive sequence of

+integers, starting at zero. However, the reality is that PNaCl records evolved

+over time (and actually started as <a class="reference external" href="http://llvm.org/docs/BitCodeFormat.html">LLVM records</a>). For backward compatibility,

+obsolete numbers have not been reused, leaving gaps in the actual record code

+values used.

+Global record codes are record codes that have the same meaning in multiple

+kinds of blocks. To separate global record codes from local record codes, large

+values are used. Currently there are four <a class="reference internal" href="#link-for-global-record-codes">global record

+codes</a>. To make these cases clear, and to leave

+ample room for future growth in PNaClAsm, these special records have record

+codes close to the value 216. Note: Well-formed PNaCl bitcode files

+do not have record codes >= 216.

+A PNaCl record is denoted as follows:

+<pre class="prettyprint">

+a: <v0, v1, ... , vN>

+</pre>

+The value <code>v0</code> is the record code. The remaining values, <code>v1</code> through

+<code>vN</code>, are parameters that fill in additional information needed by the

+construct it represents. All records must have a record code. Hence, empty PNaCl

+records are not allowed. <code>a</code> is the index to the abbreviation used to convert

+the record to a bit sequence.

+While most records (for a given record code) have the same length, it

+is not true of all record codes. Some record codes can have arbitrary

+length. In particular, function type signatures, call instructions,

+phi instructions, switch instructions, and global variable

+initialization records all have variable length. The expected length

+is predefined and part of the PNaClAsm language. See the corresponding

+construct (associated with the record) to determine the expected

+length.

+The PNaCl bitstream writer, which converts records to bit sequences, does

+this by writing out the abbreviation index used to encode the record, followed

+by the contents of the record. The details of this are left to the section on

+<a class="reference internal" href="#link-for-abbreviations-section">abbreviations</a>. However, at the record

+level, one important aspect of this appears in <a class="reference internal" href="#link-for-enter-block-record-section">block

+enter</a> records. These records must define

+how many bits are required to hold abbreviation indices associated with records

+of that block.

+<h2 id="default-abbreviations">Default Abbreviations</h2>

+There are 4 predefined (default) abbreviation indices, used as the default

+abbreviations for PNaCl records. They are:

+<dl class="docutils">

+<dt>0</dt>

+<dd>Abbreviation index for the abbreviation used to bit-encode an exit block

+record.</dd>

+<dt>1</dt>

+<dd>Abbreviation index for the abbreviation used to bit-encode an enter block

+record.</dd>

+<dt>2</dt>

+<dd>Abbreviation index for the abbreviation used to bit-encode a user-defined

+abbreviation. Note: User-defined abbreviations are also encoded as records,

+and hence need an abbreviation index to bit-encode them.</dd>

+<dt>3</dt>

+<dd>Abbreviation index for the default abbreviation to bit-encode all other

+records in the bitcode file.</dd>

+</dl>

+A block may, in addition, define a list of block specific, user-defined,

+abbreviations (of length <code>U</code>). The number of bits <code>B</code> specified for an enter

+record must be sufficiently large such that:

+<pre class="prettyprint">

+2**B >= U + 4

+</pre>

+In addition, the upper limit for <code>B</code> is <code>16</code>.

+PNaClAsm requires specifying the number of bits needed to read abbreviations as

+part of the enter block record. This allows the PNaCl bitcode reader/writer to

+use the specified number of bits to encode abbreviation indices.

+<h2 id="pnacl-identifiers">PNaCl Identifiers</h2>

+A program is defined by a <a class="reference internal" href="#link-for-module-block">module block</a>. Blocks can

+be nested within other blocks, including the module block. Each block defines a

+sequence of records.

+Most of the records, within a block, also define unique values. Each unique

+value is given a corresponding unique identifier (i.e. ID). In PNaClAsm, each

+kind of block defines its own kind of identifiers. The names of these

+identifiers are defined by concatenating a prefix character (<code>'@'</code> or

+<code>'%'</code>), the kind of block (a single character), and a suffix index. The suffix

+index is defined by the positional location of the defined value within the

+records of the corresponding block. The indices are all zero based, meaning that

+the first defined value (within a block) is defined using index 0.

+Identifiers are categorized into two types, local and global. Local

+identifiers are identifiers that are associated with the implementation of a

+single function. In that sense, they are local to the block they appear in.

+All other identifiers are global, and can appear in multiple blocks. This split

+is intentional. Global identifiers are used by multiple functions, and therefore

+must be known in all function implementations. Local identifiers only apply to a

+single function, and can be reused between functions. The <a class="reference internal" href="/native-client/overview.html#link-for-pnacl-translator">PNaCl

+translator</a> uses this separation to parallelize the

+compilation of functions.

+Note that local abbreviation identifiers are unique to the block they appear

+in. Global abbreviation identifiers are only unique to the block type they are

+defined for. Different block types can reuse global abbreviation identifiers.

+Global identifiers use the prefix character <code>'@'</code> while local identifiers use

+the prefix character <code>'%'</code>.

+Note that by using positional location to define identifiers (within a block),

+the values defined in PNaCl bitcode files need not be explicitly included in the

+bitcode file. Rather, they are inferred by the (ordered) position of the record

+in the block. This is also intentional. It is used to reduce the amount of data

+that must be (explicitly) passed to the <a class="reference internal" href="/native-client/overview.html#link-for-pnacl-translator">PNaCl

+translator</a>, when downloaded into Chrome.

+In general, most of the records within blocks are assumed to be topologically

+sorted, putting value definitions before their uses. This implies that records

+do not need to encode data if they can deduce the corresponding information from

+their uses.

+The most common use of this is that many instructions use the type of their

+operands to determine the type of the instruction. Again, this is

+intentional. It allows less information to be stored.

+However, for function blocks (which define instructions), a topological sort may

+not exist. Loop carried value dependencies simply do not allow topologically

+sorting. To deal with this, function blocks have a notion of (instruction value)

+<a class="reference internal" href="#link-for-forward-type-declaration-section">forward type

+declarations</a>. These declarations

+must appear before any of the uses of that value, if the (instruction) value is

+defined later in the function than its first use.

+The kinds of identifiers used in PNaClAsm are:

+<dl class="docutils">

+<dt>@a</dt>

+<dd>Global abbreviation identifier.</dd>

+<dt>%a</dt>

+<dd>Local abbreviation identifier.</dd>

+<dt>%b</dt>

+<dd>Function basic block identifier.</dd>

+<dt>%c</dt>

+<dd>Function constant identifier.</dd>

+<dt>@f</dt>

+<dd>Global function address identifier.</dd>

+<dt>@g</dt>

+<dd>Global variable/constant address identifier.</dd>

+<dt>%p</dt>

+<dd>Function parameter identifier.</dd>

+<dt>@t</dt>

+<dd>Global type identifier.</dd>

+<dt>%v</dt>

+<dd>Value generated by an instruction in a function block.</dd>

+</dl>

+<h2 id="conventions-for-describing-records">Conventions For Describing Records</h2>

+PNaClAsm is the textual representation of <a class="reference internal" href="#link-for-pnacl-records">PNaCl

+records</a>. Each PNaCl record is described by a

+corresponding PNaClAsm construct. These constructs are described using syntax

+rules, and semantics on how they are converted to records. Along with the rules,

+is a notion of <a class="reference internal" href="#link-for-global-state-section">global state</a>. The global

+state is updated by syntax rules. The purpose of the global state is to track

+positional dependencies between records.

+For each PNaCl construct, we define multiple sections. The Syntax

+section defines a syntax rule for the construct. The Record section

+defines the corresponding record associated with the syntax rule. The

+Semantics section describes the semantics associated with the record, in

+terms of data within the global state and the corresponding syntax. It also

+includes other high-level semantics, when appropriate.

+The Constraints section (if present) defines any constraints associated

+with the construct, including the global state. The Updates section (if

+present) defines how the global state is updated when the construct is

+processed. The Examples section gives one or more examples of using the

+corresponding PNaClAsm construct.

+Some semantics sections use functions to compute values. The meaning of

+functions can be found in <a class="reference internal" href="#link-for-support-functions-section">support

+functions</a>.

+The syntax rule may include the

+<a class="reference internal" href="#link-for-abbreviations-section">abbreviation</a> to use, when converting to a

+bit-sequence. These abbreviations, if allowed, are at the end of the construct,

+and enclosed in <code><</code> and <code>></code> brackets. These abbreviations are optional in

+the syntax, and can be omitted. If they are used, the abbreviation brackets are

+part of the actual syntax of the construct. If the abbreviation is omitted, the

+default abbreviation index is used. To make it clear that abbreviations are

+optional, syntax rules separate abbreviations using plenty of whitespace.

+Within a syntax rule, lower case characters are literal values. Sequences of

+upper case alphanumeric characters are named values. If we mix lower and upper

+case letters within a name appearing in a syntax rule, the lower case letters

+are literal while the upper case sequence of alphanumeric characters denote rule

+specific values. The valid values for each of these names will be defined in

+the corresponding semantics and constraints subsections.

+For example, consider the following syntax rule:

+<pre class="prettyprint">

+%vN = add T O1, O2; <A>

+</pre>

+This rule defines a PNaClAsm add instruction. This construct defines an

+instruction that adds two values (<code>O1</code> and <code>O2</code>) to generate instruction

+value <code>%vN</code>. The types of the arguments, and the result, are all of type

+<code>T</code>. If abbreviation ID <code>A</code> is present, the record is encoded using that

+abbreviation. Otherwise the corresponding <a class="reference internal" href="#link-for-default-abbreviations">default abbreviation

+index</a> is used.

+To be concrete, the syntactic rule above defines the structure of the following

+PNaClAsm examples:

+<pre class="prettyprint">

+%v10 = add i32 %v1, %v2; <@a5>

+%v11 = add i32 %v10, %v3;

+</pre>

+In addition to specifying the syntax, each syntax rule can also also specify the

+contents of the corresponding record in the corresponding record subsection. In

+simple cases, the elements of the corresponding record are predefined (literal)

+constants. Otherwise the record element is an identifier from another subsection

+associated with the construct.

+<h2 id="factorial-example">Factorial Example</h2>

+This section provides a simple example of a PNaCl bitcode file. Its contents

+describe a bitcode file that only defines a function to compute the factorial

+value of a number.

+In C, the factorial function can be defined as:

+<pre class="prettyprint">

+int fact(int n) {

+ if (n == 1) return 1;

+ return n * fact(n-1);

+</pre>

+Compiling this into a PNaCl bitcode file, and dumping out its contents with

+utility <a class="reference internal" href="/native-client/devguide/devcycle/building.html#pnacl-bcdis">pnacl-bcdis</a>, the corresponding output is:

+<pre class="prettyprint">

+ 0:0|<65532, 80, 69, 88, 69, 1, 0,|Magic Number: 'PEXE' (80, 69, 88, 69)

+ | 8, 0, 17, 0, 4, 0, 2, 0, 0, |PNaCl Version: 2

+ | 0> |

+ 16:0|1: <65535, 8, 2> |module { // BlockID = 8

+ 24:0| 3: <1, 1> | version 1;

+ 26:4| 1: <65535, 0, 2> | abbreviations { // BlockID = 0

+ 36:0| 0: <65534> | }

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 4> | count 4;

+ 50:4| 3: <7, 32> | @t0 = i32;

+ 53:6| 3: <2> | @t1 = void;

+ 55:4| 3: <21, 0, 0, 0> | @t2 = i32 (i32);

+ 59:4| 3: <7, 1> | @t3 = i1;

+ 62:0| 0: <65534> | }

+ 64:0| 3: <8, 2, 0, 0, 0> | define external i32 @f0(i32);

+ 68:6| 1: <65535, 19, 2> | globals { // BlockID = 19

+ 76:0| 3: <5, 0> | count 0;

+ 78:4| 0: <65534> | }

+ 80:0| 1: <65535, 14, 2> | valuesymtab { // BlockID = 14

+ 88:0| 3: <1, 0, 102, 97, 99, | @f0 : "fact";

+ | 116> |

+ 96:4| 0: <65534> | }

+100:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0) {

+ | | // BlockID = 12

+108:0| 3: <1, 3> | blocks 3;

+110:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+120:0| 3: <1, 0> | i32:

+122:4| 3: <4, 2> | %c0 = i32 1;

+125:0| 0: <65534> | }

+ | | %b0:

+128:0| 3: <28, 2, 1, 32> | %v0 = icmp eq i32 %p0, %c0;

+132:6| 3: <11, 1, 2, 1> | br i1 %v0, label %b1, label %b2;

+ | | %b1:

+136:6| 3: <10, 2> | ret i32 %c0;

+ | | %b2:

+139:2| 3: <2, 3, 2, 1> | %v1 = sub i32 %p0, %c0;

+143:2| 3: <34, 0, 5, 1> | %v2 = call i32 @f0(i32 %v1);

+148:0| 3: <2, 5, 1, 2> | %v3 = mul i32 %p0, %v2;

+152:0| 3: <10, 1> | ret i32 %v3;

+154:4| 0: <65534> | }

+156:0|0: <65534> |}

+</pre>

+Note that there are three columns in this output. The first column contains the

+bit positions of the records within the bitcode file. The second column contains

+the sequence of records within the bitcode file. The third column contains the

+corresponding PNaClAsm program.

+Bit positions are defined by a pair <code>B:N</code>. <code>B</code> is the number of bytes, while

+<code>N</code> is the bit offset within the <code>B</code>-th byte. Hence, the bit position (in

+bits) is:

+<pre class="prettyprint">

+B*8 + N

+</pre>

+Hence, the first record is at bit offset <code>0</code> (<code>0*8+0</code>). The second record is

+at bit offset <code>128</code> (<code>16*8+0</code>). The third record is at bit offset <code>192</code>

+(<code>24*8+0</code>). The fourth record is at bit offset <code>212</code> (<code>26*8+4</code>).

+The <a class="reference internal" href="#link-for-header-record-section">header record</a> is a sequence of 16

+bytes, defining the contents of the first 16 bytes of the bitcode file. These

+bytes never change, and are expected for all version 2, PNaCl bitcode files. The

+first four bytes define the magic number of the file, i.e. ‘PEXE’. All PEXE

+bitcode files begin with these four bytes.

+All but the header record has an abbreviation index associated with it. Since no

+user-defined abbreviations are provided, all records were converted to

+bit sequences using default abbreviations.

+The types block (starting at bit address <code>40:0</code>), defines 4 types: <code>i1</code>,

+<code>i32</code>, <code>void</code>, and function signature <code>i32 (i32)</code>.

+Bit address <code>64:0</code> declares the factorial function address <code>@f0</code>, and its

+corresponding type signature. Bit address <code>88:0</code> associates the name <code>fact</code>

+with function address <code>@f0</code>.

+Bit address <code>100:0</code> defines the function block that implements function

+<code>fact</code>. The entry point is <code>%b0</code> (at bit address <code>128:0</code>). It uses the

+32-bit integer constant <code>1</code> (defined at bit addresses <code>122:4</code>). Bit address

+<code>128:0</code> defines an equality comparison of the argument <code>%p0</code> with <code>1</code>

+(constant <code>%c0</code>). Bit address <code>132:6</code> defines a conditional branch. If the

+result of the previous comparison (<code>%v0</code>) is true, the program will branch to

+block <code>%b1</code>. Otherwise it will branch to block <code>%b2</code>.

+Bit address <code>136:6</code> returns constant <code>1</code> (<code>%c0</code>) when the input parameter

+is 1. Instructions between bit address <code>139:2</code> and <code>154:4</code> compute and

+return <code>n * fact(n-1)</code>.

+<h2 id="road-map">Road Map</h2>

+At this point, this document transitions from basic concepts to the details

+of how records should be formatted. This section defines the road map to

+the remaining sections in this document.

+Many records have implicit information associated with them, and must be

+maintained across records. <a class="reference internal" href="#link-for-global-state-section">Global state</a>

+describes how this implicit information is modeled. In addition, there are

+various <a class="reference internal" href="#link-for-support-functions-section">support functions</a> that are

+used to define the semantics of records, and how they update the global state.

+There are just a handful of global records (records that either don’t appear in

+any block, or can appear in all blocks). <a class="reference internal" href="#link-for-global-record-codes">Global

+records</a> describes these records. This includes

+the block delimiter records <a class="reference internal" href="#link-for-enter-block-record-section">enter</a>

+and <a class="reference internal" href="#link-for-exit-block-record-section">exit</a> that define block

+boundaries.

+PNaClAsm is a strongly typed language, and most block values are typed.

+<a class="reference internal" href="#link-for-types-block-section">types</a> describes the set of legal types, and

+how to define types.

+Global variables and their initializers are presented in the <a class="reference internal" href="#link-for-globals-block-section">globals

+block</a>. <a class="reference internal" href="#link-for-function-address-section">Function

+addresses</a> are part of the <a class="reference internal" href="#link-for-module-block">module

+block</a>, but must be defined before any global variables.

+Names to be associated with global variables and function addresses, are defined

+in the <a class="reference internal" href="#link-for-valuesymtab-block-section">valuesymtab block</a>, and must

+appear after the <a class="reference internal" href="#link-for-globals-block-section">globals block</a>, but

+before any <a class="reference internal" href="#link-for-function-blocks-section">function definition</a>.

+The <a class="reference internal" href="#link-for-module-block">module block</a> is the top-most block, and all

+other blocks must appear within the module block. The module block defines the

+executable in the bitcode file.

+Constants used within a <a class="reference internal" href="#link-for-function-blocks-section">function

+definition</a> must be defined using a

+<a class="reference internal" href="#link-for-constants-block-section">constants block</a>. Each function

+definition is defined by a <a class="reference internal" href="#link-for-function-blocks-section">function

+block</a> and constant blocks can only appear

+within function blocks. Constants defined within a constant block can only be

+used in the enclosing function block.

+Function definitions are defined by a sequence of instructions. There are

+several types of instructions.

+A <a class="reference internal" href="#link-for-terminator-instruction-section">terminator instruction</a> is the

+last instruction in a <a class="reference internal" href="#link-for-function-blocks-section">basic block</a>, and

+is a branch, return, or unreachable instruction.

+There are <a class="reference internal" href="#link-for-integer-binary-instructions">integer</a> and

+<a class="reference internal" href="#link-for-floating-point-binary-instructions">floating point</a> binary

+operations. Integer binary instructions include both arithmetic and logical

+operations. Floating point instructions define arithmetic operations.

+There are also <a class="reference internal" href="#link-for-memory-creation-and-access-instructions">memory

+access</a> instructions that

+allow one to load and store values. That section also includes how to define

+local variables using the <a class="reference internal" href="#link-for-alloca-instruction">alloca

+instruction</a>.

+One can also convert integer and floating point values using <a class="reference internal" href="#link-for-conversion-instructions">conversion

+instructions</a>.

+<a class="reference internal" href="#link-for-compare-instructions">Comparison instructions</a>

+allow you to compare values.

+<a class="reference internal" href="#link-for-vector-instructions">Vector instructions</a> allow you to build and

+update vectors. Corresponding <a class="reference internal" href="#link-for-intrinsic-functions-section">intrinsic

+functions</a>, as well as

+<a class="reference internal" href="#link-for-integer-binary-instructions">integer</a> and <a class="reference internal" href="#link-for-floating-point-binary-instructions">floating

+point</a> binary instructions allow

+you to apply operations to vectors.

+In addition, <a class="reference internal" href="#link-for-other-pnaclasm-instructions">other instructions</a> are

+available. This includes function and procedure calls.

+There are also <a class="reference internal" href="#link-for-memory-blocks-and-alignment-section">memory

+alignment</a> issues that should be

+considered for global and local variables, as well as load and store

+instructions.

+Finally, how to pack records is described in the

+<a class="reference internal" href="#link-for-abbreviations-section">abbreviations</a> section.

+<h2 id="global-state">Global State</h2>

+This section describes the global state associated with PNaClAsm. It is used to

+define contextual data that is carried between records.

+In particular, PNaClAsm is a strongly typed language, and hence, we must track

+the type associated with values. Subsection <a class="reference internal" href="#link-to-typing-functions">Typing Functions</a>

+describes the functions used to maintain typing information associated with

+values.

+Values are implicitly ordered within a block, and the indices associated with

+the values do not appear in records. Rather, ID counters are used to figure out

+what corresponding ID name is associated with a value generating record.

+Subsection <a class="reference internal" href="#link-to-id-counters">ID Counters</a> defines counters maintained in the global

+state.

+In several blocks, one of the first records in the block defines how many values

+are defined in in the block. The main purpose of these counts is to communicate

+to the <a class="reference internal" href="/native-client/overview.html#link-for-pnacl-translator">PNaCl translator</a> space requirements, or

+a limit so that it can detect bad references to values. Subsection

+<a class="reference internal" href="#link-for-size-variables">Size Variables</a> defines variables that hold size definitions in

+the corresponding records.

+Finally, the function and constants block contain implicit context between

+records in those blocks. Subsection <a class="reference internal" href="#link-to-other-variables">Other Variables</a> defines the

+variables that contain this implicit context.

+<h3 id="typing-functions">Typing Functions</h3>

+Associated with most identifiers is a type. This type defines what type the

+corresponding value has. It is defined by the (initially empty) map:

+<pre class="prettyprint">

+TypeOf: ID -> Type

+</pre>

+For each type in the <a class="reference internal" href="#link-for-types-block-section">types block</a>, a

+corresponding inverse map:

+<pre class="prettyprint">

+TypeID: Type -> ID

+</pre>

+is maintained to convert syntactic types to the corresponding type ID.

+Note: This document assumes that map <code>TypeID</code> is automatically maintained

+during updates to map <code>TypeOf</code> (when given a type <code>ID</code>). Hence, Updates

+subsections will not contain assignments to this map.

+Associated with each function identifier is its <a class="reference internal" href="#link-for-function-type">type

+signature</a>. This is different than the type of the

+function identifier, since function identifiers represent the function address

+which is a pointer (and pointers are always implemented as a 32-bit integer

+following the ILP32 data model).

+Function type signatures are maintained using:

+<pre class="prettyprint">

+TypeOfFcn: ID -> Type

+</pre>

+In addition, if a function address has an implementing block, there is a

+corresponding implementation associated with the function address. To indicate

+which function addresses have implementations, we use the set:

+<pre class="prettyprint">

+DefiningFcnIDs: set(ID)

+</pre>

+<h3 id="link-to-id-counters">ID Counters</h3>

+Each block defines one or more kinds of values. Value indices are generated

+sequentially, starting at zero. To capture this, the following counters are

+defined:

+<dl class="docutils">

+<dt>NumTypes</dt>

+<dd>The number of types defined so far (in the <a class="reference internal" href="#link-for-types-block-section">types

+block</a>).</dd>

+<dt>NumFuncAddresses</dt>

+<dd>The number of function addresses defined so far (in the <a class="reference internal" href="#link-for-module-block">module

+block</a>).</dd>

+<dt>NumGlobalAddresses</dt>

+<dd>The number of global variable/constant addresses defined so far (in the

+<a class="reference internal" href="#link-for-globals-block-section">globals block</a>).</dd>

+<dt>NumParams</dt>

+<dd>The number of parameters defined for a function. Note: Unlike other counters,

+this value is set once, at the beginning of the corresponding <a class="reference internal" href="#link-for-function-blocks-section">function

+block</a>, based on the type signature

+associated with the function.</dd>

+<dt>NumFcnConsts</dt>

+<dd>The number of constants defined in a function so far (in the corresponding

+nested <a class="reference internal" href="#link-for-constants-block-section">constants block</a>).</dd>

+<dt>NumBasicBlocks</dt>

+<dd>The number of basic blocks defined so far (within a <a class="reference internal" href="#link-for-function-blocks-section">function

+block</a>).</dd>

+<dt>NumValuedInsts</dt>

+<dd>The number of instructions, generating values, defined so far (within a

+<a class="reference internal" href="#link-for-function-blocks-section">function block</a>).</dd>

+</dl>

+<h3 id="size-variables">Size Variables</h3>

+A number of blocks define expected sizes of constructs. These sizes are recorded

+in the following size variables:

+<dl class="docutils">

+<dt>ExpectedBasicBlocks</dt>

+<dd>The expected <a class="reference internal" href="#link-for-basic-blocks-count">number of basic blocks</a> within

+a function implementation.</dd>

+<dt>ExpectedTypes</dt>

+<dd>The expected <a class="reference internal" href="#link-for-types-count-record">number of types</a> defined in

+the types block.</dd>

+<dt>ExpectedGlobals</dt>

+<dd>The expected <a class="reference internal" href="#link-for-globals-count-record">number of global variable/constant

+addresses</a> in the globals block.</dd>

+<dt>ExpectedInitializers</dt>

+<dd>The expected <a class="reference internal" href="#link-for-compound-initializer">number of initializers</a> for

+a global variable/constant address in the globals block.</dd>

+</dl>

+It is assumed that the corresponding <a class="reference internal" href="#link-to-id-counters">ID counters</a> are

+always smaller than the corresponding size variables (except

+ExpectedInitializers). That is:

+<pre class="prettyprint">

+NumBasicBlocks < ExpectedBasicBlocks

+NumTypes < ExpectedTypes

+NumGlobalAddresses < ExpectedGlobals

+</pre>

+<h3 id="other-variables">Other Variables</h3>

+<dl class="docutils">

+<dt>EnclosingFcnID</dt>

+<dd>The function ID of the function block being processed.</dd>

+<dt>ConstantsSetType</dt>

+<dd>Holds the type associated with the last <a class="reference internal" href="#link-for-constants-set-type-record">set type

+record</a> in the constants block. Note: at

+the beginning of each constants block, this variable is set to type void.</dd>

+</dl>

+<h2 id="global-records">Global Records</h2>

+Global records are records that can appear in any block. These records have

+the same meaning in multiple kinds of blocks.

+There are four global PNaCl records, each having its own record code. These

+global records are:

+<dl class="docutils">

+<dt>Header</dt>

+<dd>The <a class="reference internal" href="#link-for-header-record-section">header record</a> is the first record

+of a PNaCl bitcode file, and identifies the file’s magic number, as well as

+the bitcode version it uses. The record defines the sequence of bytes that

+make up the header and uniquely identifies the file as a PNaCl bitcode file.</dd>

+<dt>Enter</dt>

+<dd>An <a class="reference internal" href="#link-for-enter-block-record-section">enter record</a> defines the

+beginning of a block. Since blocks can be nested, one can appear inside other

+blocks, as well as at the top level.</dd>

+<dt>Exit</dt>

+<dd>An <a class="reference internal" href="#link-for-exit-block-record-section">exit record</a> defines the end of a

+block. Hence, it must appear in every block, to end the block.</dd>

+<dt>Abbreviation</dt>

+<dd>An <a class="reference internal" href="#link-for-abbreviation-record">abbreviation record</a> defines a

+user-defined abbreviation to be applied to records within blocks.

+Abbreviation records appearing in the abbreviations block define global

+abbreviations. All other abbreviations are local to the block they appear in,

+and can only be used in that block.</dd>

+</dl>

+All global records can’t have user-defined abbreviations associated with

+them. The <a class="reference internal" href="#link-for-default-abbreviations">default abbreviation</a> is always

+used.

+<h3 id="header-record">Header Record</h3>

+The header record must be the first record in the file. It is the only record in

+the bitcode file that doesn’t have a corresponding construct in PNaClAsm. In

+addition, no abbreviation index is associated with it.

+Syntax:

+There is no syntax for header records in PNaClAsm.

+Record:

+<pre class="prettyprint">

+<65532, 80, 69, 88, 69, 1, 0, 8, 0, 17, 0, 4, 0, 2, 0, 0, 0>

+</pre>

+Semantics:

+The header record defines the initial sequence of bytes that must appear at the

+beginning of all (PNaCl bitcode version 2) files. That sequence is the list of

+bytes inside the record (excluding the record code). As such, it uniquely

+identifies all PNaCl bitcode files.

+Examples:

+<pre class="prettyprint">

+0:0|<65532, 80, 69, 88, 69, 1, 0,|Magic Number: 'PEXE' (80, 69, 88, 69)

+ | 8, 0, 17, 0, 4, 0, 2, 0, 0, |PNaCl Version: 2

+ | 0> |

+</pre>

+<h3 id="enter-block-record">Enter Block Record</h3>

+Block records can be top-level, as well as nested in other blocks. Blocks must

+begin with an enter record, and end with an

+<a class="reference internal" href="#link-for-exit-block-record-section">exit</a> record.

+Syntax:

+<pre class="prettyprint">

+N {

+</pre>

+Record:

+<pre class="prettyprint">

+1: <65535, ID, B>

+</pre>

+Semantics:

+Enter block records define the beginning of a block. <code>B</code>, if present, is the

+number of bits needed to represent all possible abbreviation indices used within

+the block. If omitted, <code>B=2</code> is assumed.

+The block <code>ID</code> value is dependent on the name <code>N</code>. Valid names and

+corresponding <code>BlockID</code> values are defined as follows:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">N</th>

+<th class="head">Block ID</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>abbreviations</td>

+<td>0</td>

+</tr>

+<tr class="row-odd"><td>constants</td>

+<td>11</td>

+</tr>

+<tr class="row-even"><td>function</td>

+<td>12</td>

+</tr>

+<tr class="row-odd"><td>globals</td>

+<td>19</td>

+</tr>

+<tr class="row-even"><td>module</td>

+<td>8</td>

+</tr>

+<tr class="row-odd"><td>types</td>

+<td>17</td>

+</tr>

+<tr class="row-even"><td>valuesymtab</td>

+<td>14</td>

+</tr>

+</tbody>

+</table>

+Note: For readability, PNaClAsm defines a more readable form of a function block

+enter record. See <a class="reference internal" href="#link-for-function-blocks-section">function blocks</a> for

+more details.

+Examples:

+<pre class="prettyprint">

+16:0|1: <65535, 8, 2> |module { // BlockID = 8

+24:0| 3: <1, 1> | version 1;

+26:4| 1: <65535, 0, 2> | abbreviations { // BlockID = 0

+36:0| 0: <65534> | }

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 2> | count 2;

+50:4| 3: <2> | @t0 = void;

+52:2| 3: <21, 0, 0> | @t1 = void ();

+55:4| 0: <65534> | }

+56:0| 3: <8, 1, 0, 1, 0> | declare external void @f0();

+60:6| 1: <65535, 19, 2> | globals { // BlockID = 19

+68:0| 3: <5, 0> | count 0;

+70:4| 0: <65534> | }

+72:0|0: <65534> |}

+</pre>

+<h3 id="exit-block-record">Exit Block Record</h3>

+Block records can be top-level, as well as nested, records. Blocks must begin

+with an <a class="reference internal" href="#link-for-enter-block-record-section">enter</a> record, and end with

+an exit record.

+Syntax:

+<pre class="prettyprint">

+</pre>

+Record:

+<pre class="prettyprint">

+0: <65534>

+</pre>

+Semantics:

+All exit records are identical, no matter what block they are ending. An exit

+record defines the end of the block.

+Examples:

+<pre class="prettyprint">

+16:0|1: <65535, 8, 2> |module { // BlockID = 8

+24:0| 3: <1, 1> | version 1;

+26:4| 1: <65535, 0, 2> | abbreviations { // BlockID = 0

+36:0| 0: <65534> | }

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 2> | count 2;

+50:4| 3: <2> | @t0 = void;

+52:2| 3: <21, 0, 0> | @t1 = void ();

+55:4| 0: <65534> | }

+56:0| 3: <8, 1, 0, 1, 0> | declare external void @f0();

+60:6| 1: <65535, 19, 2> | globals { // BlockID = 19

+68:0| 3: <5, 0> | count 0;

+70:4| 0: <65534> | }

+72:0|0: <65534> |}

+</pre>

+<h3 id="abbreviation-record">Abbreviation Record</h3>

+Abbreviation records define abbreviations. See

+<a class="reference internal" href="#link-for-abbreviations-section">abbreviations</a> for details on how

+abbreviations should be written. This section only presents the mechanical

+details for converting an abbreviation into a PNaCl record.

+Syntax:

+<pre class="prettyprint">

+A = abbrev <E1, ... , EM>;

+</pre>

+Record:

+<pre class="prettyprint">

+2: <65533, M, EE1, ... , EEM>

+</pre>

+Semantics:

+Defines an abbreviation <code>A</code> as the sequence of encodings <code>E1</code> through

+<code>EM</code>. If the abbreviation appears within the <a class="reference internal" href="#link-for-abbreviations-block-section">abbreviations

+block</a>, <code>A</code> must be a global

+abbreviation. Otherwise, <code>A</code> must be a local abbreviation.

+Abbreviations within a block (or a section within the abbreviations block), must

+be enumerated in order, starting at index <code>0</code>.

+Valid encodings <code>Ei</code>, and the corresponding sequence of (unsigned) integers

+<code>EEi</code>, ( for <code>1 <= i <= M</code>) are defined by the following table:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">Ei</th>

+<th class="head">EEi</th>

+<th class="head">Form</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>C</td>

+<td>1, C</td>

+<td>Literal C in corresponding position in record.</td>

+</tr>

+<tr class="row-odd"><td>fixed(N)</td>

+<td>0, 1, N</td>

+<td>Encode value as a fixed sequence of N bits.</td>

+</tr>

+<tr class="row-even"><td>vbr(N)</td>

+<td>0, 2, N</td>

+<td>Encode value using a variable bit rate of N.</td>

+</tr>

+<tr class="row-odd"><td>char6</td>

+<td>0, 4</td>

+<td>Encode value as 6-bit char containing

+characters [a-zA-Z0-9._].</td>

+</tr>

+<tr class="row-even"><td>array</td>

+<td>0, 3</td>

+<td>Allow zero or more of the succeeding abbreviation.</td>

+</tr>

+</tbody>

+</table>

+Note that ‘array’ can only appear as the second to last element <code>Em</code>.

+Notationally, <code>Array(EM)</code> is used in place of <code>array</code> and <code>EM</code>, the last

+two entries in an abbreviation.

+Examples:

+<pre class="prettyprint">

+ 0:0|<65532, 80, 69, 88, 69, 1, 0,|Magic Number: 'PEXE' (80, 69, 88, 69)

+ | 8, 0, 17, 0, 4, 0, 2, 0, 0, |PNaCl Version: 2

+ | 0> |

+ 16:0|1: <65535, 8, 2> |module { // BlockID = 8

+ 24:0| 3: <1, 1> | version 1;

+ 26:4| 1: <65535, 0, 2> | abbreviations { // BlockID = 0

+ 36:0| 1: <1, 14> | valuesymtab:

+ 38:4| 2: <65533, 4, 0, 1, 3, 0,| @a0 = abbrev <fixed(3), vbr(8),

+ | 2, 8, 0, 3, 0, 1, 8> | array(fixed(8))>;

+ 43:2| 2: <65533, 4, 1, 1, 0, 2,| @a1 = abbrev <1, vbr(8),

+ | 8, 0, 3, 0, 1, 7> | array(fixed(7))>;

+ 48:0| 2: <65533, 4, 1, 1, 0, 2,| @a2 = abbrev <1, vbr(8),

+ | 8, 0, 3, 0, 4> | array(char6)>;

+ 52:1| 2: <65533, 4, 1, 2, 0, 2,| @a3 = abbrev <2, vbr(8),

+ | 8, 0, 3, 0, 4> | array(char6)>;

+ 56:2| 1: <1, 11> | constants:

+ 58:6| 2: <65533, 2, 1, 1, 0, 1,| @a0 = abbrev <1, fixed(2)>;

+ | 2> |

+ 61:7| 2: <65533, 2, 1, 4, 0, 2,| @a1 = abbrev <4, vbr(8)>;

+ | 8> |

+ 65:0| 2: <65533, 2, 1, 4, 1, 0>| @a2 = abbrev <4, 0>;

+ 68:1| 2: <65533, 2, 1, 6, 0, 2,| @a3 = abbrev <6, vbr(8)>;

+ | 8> |

+ 71:2| 1: <1, 12> | function:

+ 73:6| 2: <65533, 4, 1, 20, 0, | @a0 = abbrev <20, vbr(6), vbr(4),

+ | 2, 6, 0, 2, 4, 0, 2, | vbr(4)>;

+ | 4> |

+ 79:1| 2: <65533, 4, 1, 2, 0, 2,| @a1 = abbrev <2, vbr(6), vbr(6),

+ | 6, 0, 2, 6, 0, 1, 4> | fixed(4)>;

+ 84:4| 2: <65533, 4, 1, 3, 0, 2,| @a2 = abbrev <3, vbr(6),

+ | 6, 0, 1, 2, 0, 1, 4> | fixed(2), fixed(4)>;

+ 89:7| 2: <65533, 1, 1, 10> | @a3 = abbrev <10>;

+ 91:7| 2: <65533, 2, 1, 10, 0, | @a4 = abbrev <10, vbr(6)>;

+ | 2, 6> |

+ 95:0| 2: <65533, 1, 1, 15> | @a5 = abbrev <15>;

+ 97:0| 2: <65533, 3, 1, 43, 0, | @a6 = abbrev <43, vbr(6),

+ | 2, 6, 0, 1, 2> | fixed(2)>;

+101:2| 2: <65533, 4, 1, 24, 0, | @a7 = abbrev <24, vbr(6), vbr(6),

+ | 2, 6, 0, 2, 6, 0, 2, | vbr(4)>;

+ | 4> |

+106:5| 1: <1, 19> | globals:

+109:1| 2: <65533, 3, 1, 0, 0, 2,| @a0 = abbrev <0, vbr(6),

+ | 6, 0, 1, 1> | fixed(1)>;

+113:3| 2: <65533, 2, 1, 1, 0, 2,| @a1 = abbrev <1, vbr(8)>;

+ | 8> |

+116:4| 2: <65533, 2, 1, 2, 0, 2,| @a2 = abbrev <2, vbr(8)>;

+ | 8> |

+119:5| 2: <65533, 3, 1, 3, 0, 3,| @a3 = abbrev <3, array(fixed(8))>

+ | 0, 1, 8> | ;

+123:2| 2: <65533, 2, 1, 4, 0, 2,| @a4 = abbrev <4, vbr(6)>;

+ | 6> |

+126:3| 2: <65533, 3, 1, 4, 0, 2,| @a5 = abbrev <4, vbr(6), vbr(6)>;

+ | 6, 0, 2, 6> |

+130:5| 0: <65534> | }

+132:0| 1: <65535, 17, 3> | types { // BlockID = 17

+140:0| 2: <65533, 4, 1, 21, 0, | %a0 = abbrev <21, fixed(1),

+ | 1, 1, 0, 3, 0, 1, 2> | array(fixed(2))>;

+144:7| 3: <1, 3> | count 3;

+147:4| 3: <7, 32> | @t0 = i32;

+150:7| 4: <21, 0, 0, 0, 0> | @t1 = i32 (i32, i32); <%a0>

+152:7| 3: <2> | @t2 = void;

+154:6| 0: <65534> | }

+156:0| 3: <8, 1, 0, 0, 0> | define external i32 @f0(i32, i32);

+160:6| 1: <65535, 19, 4> | globals { // BlockID = 19

+168:0| 3: <5, 0> | count 0;

+170:6| 0: <65534> | }

+172:0| 1: <65535, 14, 3> | valuesymtab { // BlockID = 14

+180:0| 6: <1, 0, 102> | @f0 : "f"; <@a2>

+182:7| 0: <65534> | }

+184:0| 1: <65535, 12, 4> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+192:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+194:6| 5: <2, 2, 1, 0> | %v0 = add i32 %p0, %p1; <@a1>

+197:2| 5: <2, 3, 1, 0> | %v1 = add i32 %p0, %v0; <@a1>

+199:6| 8: <10, 1> | ret i32 %v1; <@a4>

+201:0| 0: <65534> | }

+204:0|0: <65534> |}

+</pre>

+Note that the example above shows the standard abbreviations used by

+pnacl-finalize.

+<h2 id="types-block">Types Block</h2>

+The types block defines all types used in a program. It must appear in the

+<a class="reference internal" href="#link-for-module-block">module block</a>, before any <a class="reference internal" href="#link-for-function-address-section">function

+address</a> records, the <a class="reference internal" href="#link-for-globals-block-section">globals

+block</a>, the <a class="reference internal" href="#link-for-valuesymtab-block-section">valuesymtab

+block</a>, and any <a class="reference internal" href="#link-for-function-blocks-section">function

+blocks</a>.

+All types used in a program must be defined in the types block. Many PNaClAsm

+constructs allow one to use explicit type names, rather than the type

+identifiers defined by this block. However, they are internally converted to the

+corresponding type identifier in the types block. Hence, the requirement that

+the types block must appear early in the module block.

+Each record in the types block defines a type used by the program. Types can be

+broken into the following groups:

+<dl class="docutils">

+<dt>Primitive value types</dt>

+<dd>Defines the set of base types for values. This includes various sizes of

+integer and floating point types.</dd>

+<dt>Void type</dt>

+<dd>A primitive type that doesn’t represent any value and has no size.</dd>

+<dt>Function types</dt>

+<dd>The type signatures of functions.</dd>

+<dt>Vector type</dt>

+<dd>Defines vectors of primitive types.</dd>

+</dl>

+In addition, any type that is not defined using another type is a primitive

+type. All other types (i.e. function and vector) are composite types.

+Types must be defined in a topological order, causing primitive types to appear

+before the composite types that use them. Each type must be unique. There are no

+additional restrictions on the order that types can be defined in a types block.

+The following subsections introduce each valid PNaClAsm type, and the

+corresponding PNaClAsm construct that defines the type. Types not defined in the

+types block, can’t be used in a PNaCl program.

+The first record of a types block must be a <a class="reference internal" href="#link-for-types-count-record">count

+record</a>, defining how many types are defined by the

+types block. All remaining records defines a type. The following subsections

+defines valid records within a types block. The order of type records is

+important. The position of each defining record implicitly defines the type ID

+that will be used to denote that type, within other PNaCl records of the bitcode

+file.

+To make this more concrete, consider the following example types block:

+<pre class="prettyprint">

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 4> | count 4;

+50:4| 3: <7, 32> | @t0 = i32;

+53:6| 3: <3> | @t1 = float;

+55:4| 3: <2> | @t2 = void;

+57:2| 3: <21, 0, 2, 0, 1> | @t3 = void (i32, float);

+62:0| 0: <65534> | }

+</pre>

+This example defines a types block that defines four type IDs:

+<dl class="docutils">

+<dt>@t0</dt>

+<dd>A 32-bit integer type.</dd>

+<dt>@t1</dt>

+<dd>A 32-bit floating point type.</dd>

+<dt>@t2</dt>

+<dd>The void type.</dd>

+<dt>@t3</dt>

+<dd>A function, taking 32-bit integer and float point arguments that returns

+void.</dd>

+</dl>

+<h3 id="count-record">Count Record</h3>

+The count record defines how many types are defined in the types

+block. Following the types count record are records that define types used by

+the PNaCl program.

+Syntax:

+<pre class="prettyprint">

+count N; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <1, N>

+</pre>

+Semantics:

+This construct defines the number of types used by the PNaCl program. <code>N</code> is

+the number of types defined in the types block. It is an error to define more

+(or fewer) types than value <code>N</code>, within the enclosing types block.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+0 == NumTypes

+</pre>

+Updates:

+<pre class="prettyprint">

+ExpectedTypes = N;

+</pre>

+Examples:

+<pre class="prettyprint">

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 4> | count 4;

+50:4| 3: <7, 32> | @t0 = i32;

+53:6| 3: <3> | @t1 = float;

+55:4| 3: <2> | @t2 = void;

+57:2| 3: <21, 0, 2, 0, 1> | @t3 = void (i32, float);

+62:0| 0: <65534> | }

+</pre>

+<h3 id="void-type">Void Type</h3>

+The void type record defines the void type, which corresponds to the type that

+doesn’t define any value, and has no size.

+Syntax:

+<pre class="prettyprint">

+@tN = void; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2>

+</pre>

+Semantics:

+The void type record defines the type that has no values and has no size.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+N == NumTypes

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumTypes;

+TypeOf(@tN) = void;

+</pre>

+Examples:

+<pre class="prettyprint">

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 4> | count 4;

+50:4| 3: <7, 32> | @t0 = i32;

+53:6| 3: <3> | @t1 = float;

+55:4| 3: <2> | @t2 = void;

+62:0| 0: <65534> | }

+</pre>

+<h3 id="integer-types">Integer Types</h3>

+PNaClAsm allows integer types for various bit sizes. Valid bit sizes are 1, 8,

+16, 32, and 64. Integers can be signed or unsigned, but the signed component of

+an integer is not specified by the type. Rather, individual instructions

+determine whether the value is assumed to be signed or unsigned.

+It should be noted that in PNaClAsm, all pointers are implemented as 32-bit

+(unsigned) integers. There isn’t a separate type for pointers. The only way to

+tell that a 32-bit integer is a pointer, is when it is used in an instruction

+that requires a pointer (such as load and store instructions).

+Syntax:

+<pre class="prettyprint">

+@tN = iB; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <7, B>

+</pre>

+Semantics:

+An integer type record defines an integer type. <code>B</code> defines the number of bits

+of the integer type.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+N == NumTypes &

+B in {1, 8, 16, 32, 64}

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumTypes;

+TypeOf(@tN) = iB;

+</pre>

+Examples:

+<pre class="prettyprint">

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 7> | count 7;

+50:4| 3: <7, 64> | @t0 = i64;

+53:6| 3: <7, 1> | @t1 = i1;

+56:2| 3: <7, 8> | @t2 = i8;

+58:6| 3: <7, 16> | @t3 = i16;

+61:2| 3: <7, 32> | @t4 = i32;

+64:4| 3: <21, 0, 0, 1> | @t5 = i64 (i1);

+68:4| 3: <2> | @t6 = void;

+70:2| 0: <65534> | }

+</pre>

+<h3 id="bit-floating-point-type">32-Bit Floating Point Type</h3>

+PNaClAsm allows computation on 32-bit floating point values. A floating point

+type record defines the 32-bit floating point type.

+Syntax:

+<pre class="prettyprint">

+@tN = float; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <3>

+</pre>

+Semantics:

+A floating point type record defines the 32-bit floating point type.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+N == NumTypes

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumTypes;

+TypeOf(@tN) = float;

+</pre>

+Examples:

+<pre class="prettyprint">

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 4> | count 4;

+50:4| 3: <4> | @t0 = double;

+52:2| 3: <3> | @t1 = float;

+54:0| 3: <21, 0, 0, 1> | @t2 = double (float);

+58:0| 3: <2> | @t3 = void;

+59:6| 0: <65534> | }

+</pre>

+<h3 id="id1">64-bit Floating Point Type</h3>

+PNaClAsm allows computation on 64-bit floating point values. A 64-bit floating

+type record defines the 64-bit floating point type.

+Syntax:

+<pre class="prettyprint">

+@tN = double; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <4>

+</pre>

+Semantics:

+A double type record defines the 64-bit floating point type.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+N == NumTypes

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumTypes;

+TypeOf(@tN) = double;

+</pre>

+Examples:

+<pre class="prettyprint">

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 4> | count 4;

+50:4| 3: <4> | @t0 = double;

+52:2| 3: <3> | @t1 = float;

+54:0| 3: <21, 0, 0, 1> | @t2 = double (float);

+58:0| 3: <2> | @t3 = void;

+59:6| 0: <65534> | }

+</pre>

+<h3 id="vector-types">Vector Types</h3>

+A vector type is a derived type that represents a vector of elements. Vector

+types are used when multiple primitive data values are operated in parallel

+using a single (SIMD) <a class="reference internal" href="#link-for-vector-instructions">vector instruction</a>. A

+vector type requires a size (number of elements) and an underlying primitive

+data type.

+Syntax:

+<pre class="prettyprint">

+@tN = < E x T > <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <12, E, TT>

+</pre>

+Semantics:

+The vector type defines a vector of elements. <code>T</code> is the type of each

+element. <code>E</code> is the number of elements in the vector.

+Vector types can only be defined on <code>i1</code>, <code>i8</code>, <code>i16</code>, <code>i32</code>, and

+<code>float</code>. All vector types, except those on <code>i1</code>, must contain exactly 128

+bits. The valid element sizes are restricted as follows:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">Type</th>

+<th class="head">Valid element sizes</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>i1</td>

+<td>4, 8, 16</td>

+</tr>

+<tr class="row-odd"><td>i8</td>

+<td>16</td>

+</tr>

+<tr class="row-even"><td>i16</td>

+<td>8</td>

+</tr>

+<tr class="row-odd"><td>i32</td>

+<td>4</td>

+</tr>

+<tr class="row-even"><td>float</td>

+<td>4</td>

+</tr>

+</tbody>

+</table>

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+TT == AbsoluteIndex(TypeID(T)) &

+N == NumTypes

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumTypes

+TypeOf(@tN) = <E x T>

+</pre>

+Examples:

+<pre class="prettyprint">

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 14> | count 14;

+50:4| 3: <7, 32> | @t0 = i32;

+53:6| 3: <7, 1> | @t1 = i1;

+56:2| 3: <2> | @t2 = void;

+58:0| 3: <12, 4, 1> | @t3 = <4 x i1>;

+61:2| 3: <12, 8, 1> | @t4 = <8 x i1>;

+64:4| 3: <12, 16, 1> | @t5 = <16 x i1>;

+67:6| 3: <7, 8> | @t6 = i8;

+70:2| 3: <12, 16, 6> | @t7 = <16 x i8>;

+73:4| 3: <7, 16> | @t8 = i16;

+76:0| 3: <12, 8, 8> | @t9 = <8 x i16>;

+79:2| 3: <12, 4, 0> | @t10 = <4 x i32>;

+82:4| 3: <3> | @t11 = float;

+84:2| 3: <12, 4, 11> | @t12 = <4 x float>;

+87:4| 3: <21, 0, 2> | @t13 = void ();

+90:6| 0: <65534> | }

+</pre>

+<h3 id="function-type">Function Type</h3>

+The function type can be thought of as a function signature. It consists of a

+return type, and a (possibly empty) list of formal parameter types.

+Syntax:

+<pre class="prettyprint">

+%tN = RT (T1, ... , TM) <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <21, 0, IRT, IT1, ... , ITM>

+</pre>

+Semantics:

+The function type defines the signature of a function. <code>RT</code> is the return type

+of the function, while types <code>T1</code> through <code>TM</code> are the types of the

+arguments. Indices to the corresponding type identifiers are stored in the

+corresponding record.

+The return value must either be a primitive type, type <code>void</code>, or a vector

+type. Parameter types can be a primitive or vector type.

+For ordinary functions, the only valid integer types that can be used for a

+return or parameter type are <code>i32</code> and <code>i64</code>. All other integer types are

+not allowed.

+For <a class="reference internal" href="#link-for-intrinsic-functions-section">intrinsic functions</a>, all

+integer types are allowed for both return and parameter types.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+M >= 0 &

+IRT == AbsoluteIndex(TypeID(RT)) &

+IT1 == AbsoluteIndex(TypeID(T1)) &

+...

+ITM == AbsoluteIndex(TypeID(TM)) &

+N == NumTypes

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumTypes

+TypeOf(@tN) = RT (T1, ... , TM)

+</pre>

+Examples:

+<pre class="prettyprint">

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 7> | count 7;

+50:4| 3: <7, 32> | @t0 = i32;

+53:6| 3: <3> | @t1 = float;

+55:4| 3: <4> | @t2 = double;

+57:2| 3: <21, 0, 2, 1> | @t3 = double (float);

+61:2| 3: <2> | @t4 = void;

+63:0| 3: <21, 0, 4> | @t5 = void ();

+66:2| 3: <21, 0, 0, 0, 1, 0, 2>| @t6 =

+ | | i32 (i32, float, i32, double);

+72:4| 0: <65534> | }

+</pre>

+<h2 id="globals-block">Globals Block</h2>

+The globals block defines global addresses of variables and constants, used by

+the PNaCl program. It also defines the memory associated with the global

+addresses, and how to initialize each global variable/constant. It must appear

+in the <a class="reference internal" href="#link-for-module-block">module block</a>. It must appear after the

+<a class="reference internal" href="#link-for-types-block-section">types block</a>, as well as after all

+<a class="reference internal" href="#link-for-function-address-section">function address</a> records. But, it must

+also appear before the <a class="reference internal" href="#link-for-valuesymtab-block-section">valuesymtab

+block</a>, and any

+<a class="reference internal" href="#link-for-function-blocks-section">function blocks</a>.

+The globals block begins with a <a class="reference internal" href="#link-for-globals-count-record">count

+record</a>, defining how many global addresses are

+defined by the PNaCl program. It is then followed by a sequence of records that

+defines each global address, and how each global address is initialized.

+The standard sequence, for defining global addresses, begins with a global

+address record. It is then followed by a sequence of records defining how the

+global address is initialized. If the initializer is simple, a single record is

+used. Otherwise, the initializer is preceded with a <a class="reference internal" href="#link-for-compound-initializer">compound

+record</a>, specifying a number N, followed by

+sequence of N simple initializer records.

+The size of the memory referenced by each global address is defined by its

+initializer records. All simple initializer records define a sequence of

+bytes. A compound initializer defines the sequence of bytes by concatenating the

+corresponding sequence of bytes for each of its simple initializer records.

+For notational convenience, PNaClAsm begins a compound record with a “{”, and

+inserts a “}” after the last initializer record associated with the compound

+record. This latter “}” does not correspond to any record. It is implicitly

+assumed by the size specified in the compound record, and is added only to

+improve readability.

+Explicit alignment is specified for global addresses, and must be a power of

+2. See <a class="reference internal" href="#link-for-memory-blocks-and-alignment-section">memory blocks and

+alignment</a> for a more detailed

+discussion on how to define alignment.

+For example, consider the following pnacl-bcdis output snippet:

+<pre class="prettyprint">

+52:0| 1: <65535, 19, 2> | globals { // BlockID = 19

+60:0| 3: <5, 2> | count 2;

+62:4| 3: <0, 1, 1> | const @g0, align 1,

+65:6| 3: <2, 8> | zerofill 8;

+68:2| 3: <0, 1, 0> | var @g1, align 1,

+71:4| 3: <1, 2> | initializers 2 {

+74:0| 3: <3, 1, 2, 3, 4> | { 1, 2, 3, 4}

+78:6| 3: <2, 2> | zerofill 2;

+ | | }

+81:2| 0: <65534> | }

+</pre>

+This snippet defines the global constant <code>@g0</code>, and the global variable

+<code>@g1</code>. <code>@g0</code> is 8 bytes long, and initialized to zero. <code>@g1</code> is

+initialized with 6 bytes: <code>1 2 3 4 0 0</code>.

+<h3 id="link-for-globals-count-record">Count Record</h3>

+The count record defines the number of global addresses used by the PNaCl

+program.

+Syntax:

+<pre class="prettyprint">

+count N; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <5, N>

+</pre>

+Semantics:

+This record must appear first in the globals block. The count record defines

+the number of global addresses used by the program.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+</pre>

+Updates:

+<pre class="prettyprint">

+ExpectedGlobals = N;

+ExpectedInitializers = 0;

+</pre>

+Examples:

+<pre class="prettyprint">

+52:0| 1: <65535, 19, 2> | globals { // BlockID = 19

+60:0| 3: <5, 2> | count 2;

+62:4| 3: <0, 1, 1> | const @g0, align 1,

+65:6| 3: <2, 8> | zerofill 8;

+68:2| 3: <0, 1, 0> | var @g1, align 1,

+71:4| 3: <1, 2> | initializers 2 {

+74:0| 3: <3, 1, 2, 3, 4> | { 1, 2, 3, 4}

+78:6| 3: <2, 2> | zerofill 2;

+ | | }

+81:2| 0: <65534> | }

+</pre>

+<h3 id="global-variable-addresses">Global Variable Addresses</h3>

+A global variable address record defines a global address to global data. The

+global variable address record must be immediately followed by initializer

+record(s) that define how the corresponding global variable is initialized.

+Syntax:

+<pre class="prettyprint">

+var @gN, align V, <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <0, VV, 0>

+</pre>

+Semantics:

+A global variable address record defines a global address for a global variable.

+<code>V</code> is the <a class="reference internal" href="#link-for-memory-blocks-and-alignment-section">memory

+alignment</a> for the global variable

+address, and is a power of 2.

+It is assumed that the memory, referenced by the global variable address, can be

+both read and written to.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+N == NumGlobalAddresses &

+ExpectedInitializers == 0 &

+VV == Log2(V+1)

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumGlobalAddresses;

+ExpectedInitializers = 1;

+TypeOf(@gN) = i32;

+</pre>

+Examples:

+<pre class="prettyprint">

+52:0| 1: <65535, 19, 2> | globals { // BlockID = 19

+60:0| 3: <5, 2> | count 2;

+62:4| 3: <0, 3, 0> | var @g0, align 4,

+65:6| 3: <2, 8> | zerofill 8;

+68:2| 3: <0, 1, 0> | var @g1, align 1,

+71:4| 3: <3, 1, 2, 3, 4> | { 1, 2, 3, 4}

+76:2| 0: <65534> | }

+80:0|0: <65534> |}

+</pre>

+<h3 id="global-constant-addresses">Global Constant Addresses</h3>

+A global constant address record defines an address corresponding to a global

+constant that can’t be modified by the program. The global constant address

+record must be immediately followed by initializer record(s) that define how

+the corresponding global constant is initialized.

+Syntax:

+<pre class="prettyprint">

+const @gN, align V, <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <0, VV, 1>

+</pre>

+Semantics:

+A global constant address record defines a global address for a global constant.

+<code>V</code> is the <a class="reference internal" href="#link-for-memory-blocks-and-alignment-section">memory

+alignment</a> for the global constant

+address, and is a power of 2.

+It is assumed that the memory, referenced by the global constant address, is

+only read, and can’t be written to.

+Note that the only difference between a global variable address and a global

+constant address record is the third element of the record. If the value is

+zero, it defines a global variable address. If the value is one, it defines a

+global constant address.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+N == NumGlobalAddresses &

+ExpectedInitializers == 0 &

+VV == Log2(V+1)

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumGlobalAddresses;

+ExpectedInitializers = 1;

+TypeOf(@gN) = i32;

+</pre>

+Examples:

+<pre class="prettyprint">

+52:0| 1: <65535, 19, 2> | globals { // BlockID = 19

+60:0| 3: <5, 2> | count 2;

+62:4| 3: <0, 3, 1> | const @g0, align 4,

+65:6| 3: <2, 8> | zerofill 8;

+68:2| 3: <0, 1, 1> | const @g1, align 1,

+71:4| 3: <3, 1, 2, 3, 4> | { 1, 2, 3, 4}

+76:2| 0: <65534> | }

+</pre>

+<h3 id="zerofill-initializer">Zerofill Initializer</h3>

+The zerofill initializer record initializes a sequence of bytes, associated with

+a global address, with zeros.

+Syntax:

+<pre class="prettyprint">

+zerofill N; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, N>

+</pre>

+Semantics:

+A zerofill initializer record initializes a sequence of bytes, associated with a

+global address, with zeros. The number of bytes initialized to zero is <code>N</code>.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+ExpectedInitializers > 0

+</pre>

+Updates:

+<pre class="prettyprint">

+--ExpectedInitializers;

+</pre>

+Examples:

+<pre class="prettyprint">

+52:0| 1: <65535, 19, 2> | globals { // BlockID = 19

+60:0| 3: <5, 2> | count 2;

+62:4| 3: <0, 3, 1> | const @g0, align 4,

+65:6| 3: <2, 8> | zerofill 8;

+68:2| 3: <0, 1, 0> | var @g1, align 1,

+71:4| 3: <2, 4> | zerofill 4;

+74:0| 0: <65534> | }

+</pre>

+<h3 id="data-initializer">Data Initializer</h3>

+Data records define a sequence of bytes. These bytes define the initial value of

+the contents of the corresponding memory.

+Syntax:

+<pre class="prettyprint">

+{ B1 , .... , BN } <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <3, B1, ..., BN>

+</pre>

+Semantics:

+A data record defines a sequence of (unsigned) bytes <code>B1</code> through <code>BN</code>, that

+initialize <code>N</code> bytes of memory.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+ExpectedInitializers > 0

+</pre>

+Updates:

+<pre class="prettyprint">

+--ExpectedInitializers;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 56:0| 3: <8, 1, 0, 1, 0> | declare external void @f0();

+ 60:6| 1: <65535, 19, 2> | globals { // BlockID = 19

+ 68:0| 3: <5, 2> | count 2;

+ 70:4| 3: <0, 1, 1> | const @g0, align 1,

+ 73:6| 3: <3, 1, 2, 97, 36, 44, | { 1, 2, 97, 36, 44, 88,

+ | 88, 44, 50> | 44, 50}

+ 86:0| 3: <0, 1, 1> | const @g1, align 1,

+ 89:2| 3: <1, 3> | initializers 3 {

+ 91:6| 3: <3, 1, 2, 3, 4> | { 1, 2, 3, 4}

+ 96:4| 3: <4, 0> | reloc @f0;

+ 99:0| 3: <3, 99, 66, 22, 12> | { 99, 66, 22, 12}

+ | | }

+105:2| 0: <65534> | }

+</pre>

+<h3 id="relocation-initializer">Relocation Initializer</h3>

+A relocation initializer record allows one to define the initial value of a

+global address with the value of another global address (i.e. either

+<a class="reference internal" href="#link-for-function-address-section">function</a>,

+<a class="reference internal" href="#link-for-global-variable-address">variable</a>, or

+<a class="reference internal" href="#link-for-global-constant-address">constant</a>). Since addresses are

+pointers, a relocation initializer record defines 4 bytes of memory.

+Syntax:

+<pre class="prettyprint">

+reloc V; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <4, VV>

+</pre>

+Semantics:

+A relocation initializer record defines a 4-byte value containing the specified

+global address <code>V</code>.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV == AbsoluteIndex(V) &

+VV >= NumFuncAddresses &

+VV < NumFuncAddresses + ExpectedGlobals &

+ExpectedInitializers > 0

+</pre>

+Updates:

+<pre class="prettyprint">

+--ExpectedInitializers;

+</pre>

+Examples:

+<pre class="prettyprint">

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 2> | count 2;

+50:4| 3: <2> | @t0 = void;

+52:2| 3: <21, 0, 0> | @t1 = void ();

+55:4| 0: <65534> | }

+56:0| 3: <8, 1, 0, 1, 0> | declare external void @f0();

+60:6| 1: <65535, 19, 2> | globals { // BlockID = 19

+68:0| 3: <5, 2> | count 2;

+70:4| 3: <0, 1, 0> | var @g0, align 1,

+73:6| 3: <1, 3> | initializers 3 {

+76:2| 3: <4, 0> | reloc @f0;

+78:6| 3: <4, 1> | reloc @g0;

+81:2| 3: <4, 2> | reloc @g1;

+ | | }

+83:6| 3: <0, 3, 0> | var @g1, align 4,

+87:0| 3: <2, 4> | zerofill 4;

+89:4| 0: <65534> | }

+</pre>

+This example defines global address <code>@g0</code> and <code>@g1</code>. <code>@g0</code> defines 12

+bytes of memory, and is initialized with three addresses <code>@f1</code>, <code>@g0</code>, and

+<code>@g1</code>. Note that all global addresses can be used in a relocation

+initialization record, even if it isn’t defined yet.

+<h3 id="subfield-relocation-initializer">Subfield Relocation Initializer</h3>

+A subfield relocation initializer record allows one to define the initial value

+of a global address with the value of another (non-function) global address

+(i.e. either <a class="reference internal" href="#link-for-global-variable-address">variable</a> or

+<a class="reference internal" href="#link-for-global-constant-address">constant</a> address), plus a

+constant. Since addresses are pointers, a relocation initializer record defines

+4 bytes of memory.

+Syntax:

+<pre class="prettyprint">

+reloc V + X; <A>

+reloc V - X; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <4, VV, XXX>

+</pre>

+Semantics:

+A subfield relocation initializer record defines a 4-byte value containing the

+specified global (non-function) address <code>V</code>, modified by the unsigned offset

+<code>X</code>. <code>XX</code> is the corresponding signed offset. In the first form, <code>XX ==

+X</code>. In the second form, <code>XX == -X</code>.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+VV == AbsoluteIndex(V)

+VV >= NumFuncAddresses

+VV < NumFuncAddresses + ExpectedGlobals

+ExpectedInitializers > 0

+XXX == SignRotate(XX)

+</pre>

+Updates:

+<pre class="prettyprint">

+--ExpectedInitializers;

+</pre>

+Examples:

+<pre class="prettyprint">

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 0> | count 0;

+50:4| 0: <65534> | }

+52:0| 1: <65535, 19, 2> | globals { // BlockID = 19

+60:0| 3: <5, 3> | count 3;

+62:4| 3: <0, 1, 0> | var @g0, align 1,

+65:6| 3: <1, 3> | initializers 3 {

+68:2| 3: <4, 0, 1> | reloc @g0 + 1;

+71:4| 3: <4, 1, 4294967295> | reloc @g1 - 1;

+79:2| 3: <4, 2, 4> | reloc @g2 + 4;

+ | | }

+82:4| 3: <0, 3, 0> | var @g1, align 4,

+85:6| 3: <2, 4> | zerofill 4;

+88:2| 3: <0, 3, 0> | var @g2, align 4,

+91:4| 3: <2, 8> | zerofill 8;

+94:0| 0: <65534> | }

+</pre>

+<h3 id="compound-initializer">Compound Initializer</h3>

+The compound initializer record must immediately follow a global

+<a class="reference internal" href="#link-for-global-variable-address">variable</a> or

+<a class="reference internal" href="#link-for-global-constant-address">constant</a> address record. It defines how

+many simple initializer records are used to define the initializer. The size of

+the corresponding memory is the sum of the bytes needed for each of the

+succeeding initializers.

+Note that a compound initializer can’t be used as a simple initializer of

+another compound initializer (i.e. nested compound initializers are not

+allowed).

+Syntax:

+<pre class="prettyprint">

+initializers N { <A>

+ ...

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <1, N>

+</pre>

+Semantics:

+Defines that the next <cite>N</cite> initializers should be associated with the global

+address of the previous record.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+ExpectedInitializers == 1

+</pre>

+Updates:

+<pre class="prettyprint">

+ExpectedInitializers = N;

+</pre>

+Examples:

+<pre class="prettyprint">

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 0> | count 0;

+50:4| 0: <65534> | }

+52:0| 1: <65535, 19, 2> | globals { // BlockID = 19

+60:0| 3: <5, 2> | count 2;

+62:4| 3: <0, 0, 1> | const @g0, align 0,

+65:6| 3: <1, 2> | initializers 2 {

+68:2| 3: <2, 8> | zerofill 8;

+70:6| 3: <3, 3, 2, 1, 0> | { 3, 2, 1, 0}

+ | | }

+75:4| 3: <0, 0, 0> | var @g1, align 0,

+78:6| 3: <1, 2> | initializers 2 {

+81:2| 3: <3, 1, 2, 3, 4> | { 1, 2, 3, 4}

+86:0| 3: <2, 2> | zerofill 2;

+ | | }

+88:4| 0: <65534> | }

+</pre>

+<h2 id="valuesymtab-block">Valuesymtab Block</h2>

+The valuesymtab block does not define any values. Its only goal is to associate

+text names with external <a class="reference internal" href="#link-for-function-address-section">function

+addresses</a>. Each association is defined by a

+record in the valuesymtab block. Currently, only

+<a class="reference internal" href="#link-for-intrinsic-functions-section">intrinsic</a> function addresses and

+the (external) start function (<code>_start</code>) can be named. All named function

+addresses must be external. Each record in the valuesymtab block is a entry

+record, defining a single name association.

+<h3 id="entry-record">Entry Record</h3>

+The entry record defines a name for a function address.

+Syntax:

+<pre class="prettyprint">

+V : "NAME"; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <1, B1, ... , BN>

+</pre>

+Semantics:

+The entry record defines a name <code>NAME</code> for function address <code>V</code>. <code>NAME</code>

+is a sequence of ASCII characters <code>B1</code> through <code>BN</code>.

+Examples:

+<pre class="prettyprint">

+ 72:0| 3: <8, 4, 0, 1, 0> | declare external

+ | | void @f0(i32, i32, i32, i32, i1);

+ 76:6| 3: <8, 4, 0, 1, 0> | declare external

+ | | void @f1(i32, i32, i32, i32, i1);

+ 81:4| 3: <8, 5, 0, 0, 0> | define external void @f2(i32);

+ 86:2| 1: <65535, 19, 2> | globals { // BlockID = 19

+ 92:0| 3: <5, 0> | count 0;

+ 94:4| 0: <65534> | }

+ 96:0| 1: <65535, 14, 2> | valuesymtab { // BlockID = 14

+104:0| 3: <1, 1, 108, 108, 118, | @f1 : "llvm.memmove.p0i8.p0i8.i32";

+ | 109, 46, 109, 101, |

+ | 109, 109, 111, 118, |

+ | 101, 46, 112, 48, |

+ | 105, 56, 46, 112, 48,|

+ | 105, 56, 46, 105, 51,|

+ | 50> |

+145:4| 3: <1, 2, 95, 115, 116, | @f2 : "_start";

+ | 97, 114, 116> |

+157:0| 3: <1, 0, 108, 108, 118, | @f0 : "llvm.memcpy.p0i8.p0i8.i32";

+ | 109, 46, 109, 101, |

+ | 109, 99, 112, 121, |

+ | 46, 112, 48, 105, 56,|

+ | 46, 105, 51, 50> |

+197:0| 0: <65534> | }

+</pre>

+<h2 id="module-block">Module Block</h2>

+The module block, like all blocks, is enclosed in a pair of

+<a class="reference internal" href="#link-for-enter-block-record-section">enter</a> /

+<a class="reference internal" href="#link-for-exit-block-record-section">exit</a> records, using block ID 8. A

+well-formed module block consists of the following records (in order):

+<dl class="docutils">

+<dt>A version record</dt>

+<dd>The <a class="reference internal" href="#link-for-version-record">version record</a> communicates which version

+of the PNaCl bitcode reader/writer should be used. Note that this is

+different than the PNaCl bitcode (ABI) version. The PNaCl bitcode (ABI)

+version defines what is expected in records, and is defined in the header

+record of the bitcode file. The version record defines the version of the

+PNaCl bitcode reader/writer to use to convert records into bit sequences.</dd>

+<dt>Optional local abbreviations</dt>

+<dd>Defines a list of local <a class="reference internal" href="#link-for-abbreviations-section">abbreviations</a>

+to use for records within the module block.</dd>

+<dt>An abbreviations block</dt>

+<dd>The <a class="reference internal" href="#link-for-abbreviations-block-section">abbreviations block</a> defines

+user-defined, global abbreviations that are used to convert PNaCl records to

+bit sequences in blocks following the abbreviations block.</dd>

+<dt>A types block</dt>

+<dd>The <a class="reference internal" href="#link-for-types-block-section">types block</a> defines the set of all

+types used in the program.</dd>

+<dt>A non-empty sequence of function address records</dt>

+<dd>Each record defines a <a class="reference internal" href="#link-for-function-address-section">function

+address</a> used by the program. Function

+addresses must either be external, or defined internally by the program. If

+they are defined by the program, there must be a <a class="reference internal" href="#link-for-function-blocks-section">function

+block</a> (appearing later in the module) that

+defines the sequence of instructions for each defined function.</dd>

+<dt>A globals block defining the global variables.</dt>

+<dd>This <a class="reference internal" href="#link-for-globals-block-section">block</a> defines the set of

+global <a class="reference internal" href="#link-for-global-variable-address">variable</a> and

+<a class="reference internal" href="#link-for-global-constant-address">constant</a> addresses used by the

+program. In addition to the addresses, each global variable also defines how

+the corresponding global variable is initialized.</dd>

+<dt>An optional value symbol table block.</dt>

+<dd>This <a class="reference internal" href="#link-for-valuesymtab-block-section">block</a>, if defined, provides

+textual names for <a class="reference internal" href="#link-for-function-address-section">function

+addresses</a> (previously defined in the

+module). Note that only names for intrinsic functions and the start function

+are specified.</dd>

+<dt>A sequence of function blocks.</dt>

+<dd>Each <a class="reference internal" href="#link-for-function-blocks-section">function block</a> defines the

+corresponding intermediate representation for each defined function. The

+order of function blocks is used to associate them with <a class="reference internal" href="#link-for-function-address-section">function

+addresses</a>. The order of the defined

+function blocks must follow the same order as the corresponding function

+addresses defined in the module block.</dd>

+</dl>

+Descriptions of the <a class="reference internal" href="#link-for-abbreviations-section">abbreviations</a>,

+<a class="reference internal" href="#link-for-types-block-section">types</a>,

+<a class="reference internal" href="#link-for-globals-block-section">globals</a>, <a class="reference internal" href="#link-for-valuesymtab-block-section">value symbol

+table</a>, and

+<a class="reference internal" href="#link-for-function-blocks-section">function</a> blocks are not provided

+here. See the appropriate reference for more details. The following subsections

+describe each of the records that can appear in a module block.

+<h3 id="version-record">Version Record</h3>

+The version record defines the implementation of the PNaCl bitstream

+reader/writer to use. That is, the implementation that converts PNaCl records to

+bit sequences, and converts them back to PNaCl records. Note that this is

+different than the PNaCl version of the bitcode file (encoded in the header

+record of the bitcode file). The PNaCl version defines the valid forms of PNaCl

+records. The version record is specific to the PNaCl version, and may have

+different values for different PNaCl versions.

+Note that currently, only PNaCl bitcode version 2, and version record value 1 is

+defined.

+Syntax:

+<pre class="prettyprint">

+version N; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <1, N>

+</pre>

+Semantics:

+The version record defines which PNaCl reader/writer rules should be

+followed. <code>N</code> is the version number. Currently <code>N</code> must be 1. Future

+versions of PNaCl may define additional legal values.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+</pre>

+Examples:

+<pre class="prettyprint">

+16:0|1: <65535, 8, 2> |module { // BlockID = 8

+24:0| 3: <1, 1> | version 1;

+26:4| 1: <65535, 0, 2> | abbreviations { // BlockID = 0

+36:0| 0: <65534> | }

+</pre>

+<h3 id="function-address">Function Address</h3>

+A function address record describes a function address. Defined function

+addresses define <a class="reference internal" href="#link-for-function-blocks-section">implementations</a> while

+declared function addresses do not.

+Since a PNaCl program is assumed to be a complete (statically linked)

+executable, All functions should be defined and internal. The exception to

+this are <a class="reference internal" href="#link-for-intrinsic-functions-section">intrinsic functions</a>, which

+should only be declared and external, since intrinsic functions will be

+automatically converted to appropriate code by the <a class="reference internal" href="/native-client/overview.html#link-for-pnacl-translator">PNaCl

+translator</a>.

+The implementation of a defined function address is provided by a

+corresponding function block, appearing later in the module block. The

+association of a defined function address with the corresponding function

+block is based on position. The Nth defined function address record, in the

+module block, has its implementation in the Nth function block of that module

+block.

+Syntax:

+<pre class="prettyprint">

+PN LN T0 @fN ( T1 , ... , TM ); <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <8, T, C, P, L>

+</pre>

+Semantics:

+Describes the function address <code>@fN</code>. <code>PN</code> is the name that specifies the

+prototype value <code>P</code> associated with the function. A function address is

+defined only if <code>P == 0</code>. Otherwise, it is only declared. The type of the

+function is <a class="reference internal" href="#link-for-function-type">function type</a> <code>@tT</code>. <code>L</code> is the

+linkage specification corresponding to name <code>LN</code>. <code>C</code> is the calling

+convention used by the function.

+Note that function signature must be defined by a function type in the types

+block. Hence, the return value must either be a primitive type, type <code>void</code>,

+or a vector type.

+For ordinary functions, integer parameter and types can only be <code>i32</code> and

+<code>i64</code>. All other integer types are not allowed. For intrinsic functions, all

+integer types are allowed.

+Valid prototype names <code>PN</code>, and corresponding <code>P</code> values, are:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">P</th>

+<th class="head">PN</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>1</td>

+<td>declare</td>

+</tr>

+<tr class="row-odd"><td>0</td>

+<td>define</td>

+</tr>

+</tbody>

+</table>

+Valid linkage names <code>LN</code>, and corresponding <code>L</code> values, are:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">L</th>

+<th class="head">LN</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>3</td>

+<td>internal</td>

+</tr>

+<tr class="row-odd"><td>0</td>

+<td>external</td>

+</tr>

+</tbody>

+</table>

+Currently, only one calling convention <code>C</code> is supported:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">C</th>

+<th class="head">Calling Convention</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>0</td>

+<td>C calling convention</td>

+</tr>

+</tbody>

+</table>

+Constraints:

+<pre class="prettyprint">

+AA = AbbrevIndex(A) &

+T = TypeID(TypeOf(T0 ( T1 , ... , TN ))) &

+N = NumFuncAddresses

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumFuncAddresses;

+TypeOf(@fN) = TypeOf(TypeID(i32));

+TypeOfFcn(@fN) = TypeOf(@tT);

+if PN == 0:

+ DefiningFcnIDs += @FN;

+ ++NumDefinedFunctionAddresses;

+</pre>

+Examples:

+<pre class="prettyprint">

+40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+48:0| 3: <1, 7> | count 7;

+50:4| 3: <7, 32> | @t0 = i32;

+53:6| 3: <3> | @t1 = float;

+55:4| 3: <4> | @t2 = double;

+57:2| 3: <2> | @t3 = void;

+59:0| 3: <21, 0, 2, 1> | @t4 = double (float);

+63:0| 3: <21, 0, 0, 0, 1, 0, 2>| @t5 =

+ | | i32 (i32, float, i32, double);

+69:2| 3: <21, 0, 3> | @t6 = void ();

+72:4| 0: <65534> | }

+76:0| 3: <8, 4, 0, 1, 0> | declare external double @f0(float);

+80:6| 3: <8, 5, 0, 1, 0> | declare external

+ | | i32 @f1(i32, float, i32, double);

+85:4| 3: <8, 6, 0, 0, 0> | define external void @f2();

+</pre>

+<h2 id="constants-blocks">Constants Blocks</h2>

+Constants blocks define literal constants used within each function. Its intent

+is to define them once, before instructions. A constants block can only appear

+in a <a class="reference internal" href="#link-for-function-blocks-section">function block</a>, and must appear

+before any instructions in the function block.

+Currently, only integer literals, floating point literals, and undefined vector

+constants can be defined.

+To minimize type information put in a constants block, the type information is

+separated from the constants. This allows a sequence of constants to be given

+the same type. This is done by defining a <a class="reference internal" href="#link-for-constants-set-type-record">set type

+record</a>, followed by a sequence of literal

+constants. These literal constants all get converted to the type of the

+preceding set type record.

+Note that constants that are used for switch case selectors should not be added

+to the constants block, since the switch instruction contains the constants used

+for case selectors. All other constants in the function block must be put into a

+constants block, so that instructions can use them.

+To make this more concrete, consider the following example constants block:

+<pre class="prettyprint">

+106:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+116:0| 3: <1, 0> | i32:

+118:4| 3: <4, 2> | %c0 = i32 1;

+121:0| 3: <4, 4> | %c1 = i32 2;

+123:4| 3: <1, 2> | i8:

+126:0| 3: <4, 8> | %c2 = i8 4;

+128:4| 3: <4, 6> | %c3 = i8 3;

+131:0| 3: <1, 1> | float:

+133:4| 3: <6, 1065353216> | %c4 = float 1;

+139:6| 0: <65534> | }

+</pre>

+<h3 id="set-type-record">Set Type Record</h3>

+The set type record defines the type to use for the (immediately) succeeding

+literals.

+Syntax:

+<pre class="prettyprint">

+T: <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <1, TT>

+</pre>

+Semantics:

+The set type record defines type <code>T</code> to be used to type the (immediately)

+succeeding literals. <code>T</code> must be a non-void primitive value type or a vector

+type.

+Constraints:

+<pre class="prettyprint">

+TT == TypeID(T)

+</pre>

+Updates:

+<pre class="prettyprint">

+ConstantsSetType = T;

+</pre>

+Examples:

+<pre class="prettyprint">

+106:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+116:0| 3: <1, 0> | i32:

+118:4| 3: <4, 2> | %c0 = i32 1;

+121:0| 3: <4, 4> | %c1 = i32 2;

+123:4| 3: <1, 2> | i8:

+126:0| 3: <4, 8> | %c2 = i8 4;

+128:4| 3: <4, 6> | %c3 = i8 3;

+131:0| 3: <1, 1> | float:

+133:4| 3: <6, 1065353216> | %c4 = float 1;

+139:6| 0: <65534> | }

+</pre>

+<h3 id="undefined-literal">Undefined Literal</h3>

+The undefined literal record creates an undefined literal for the type T

+defined by the preceding set type record.

+Note: See <a class="reference internal" href="#link-for-insert-element-instruction-section">insert element

+instruction</a> for an example of how

+you would use the undefined literal with vector types.

+Syntax:

+<pre class="prettyprint">

+%cN = T undef; <50>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <3>

+</pre>

+Semantics:

+The undefined literal record creates an undefined literal constant <code>%cN</code> for

+type <code>T</code>. <code>T</code> must be the type defined by the preceding set type record,

+and be a primitive value type or a vector type.

+Constraints:

+<pre class="prettyprint">

+N == NumFcnConsts &

+T == ConstantsSetType &

+IsPrimitive(T) or IsVector(T)

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumFcnConsts;

+TypeOf(%cN) = T;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 5> | count 5;

+ 50:4| 3: <7, 32> | @t0 = i32;

+ 53:6| 3: <3> | @t1 = float;

+ 55:4| 3: <2> | @t2 = void;

+ 57:2| 3: <12, 4, 0> | @t3 = <4 x i32>;

+ 60:4| 3: <21, 0, 2> | @t4 = void ();

+ 63:6| 0: <65534> | }

+ ...

+106:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+116:0| 3: <1, 0> | i32:

+118:4| 3: <3> | %c0 = i32 undef;

+120:2| 3: <4, 2> | %c1 = i32 1;

+122:6| 3: <1, 3> | <4 x i32>:

+125:2| 3: <3> | %c2 = <4 x i32> undef;

+127:0| 3: <1, 1> | float:

+129:4| 3: <3> | %c3 = float undef;

+131:2| 0: <65534> | }

+</pre>

+<h3 id="integer-literal">Integer Literal</h3>

+The integer literal record creates an integer literal for the integer type T

+defined by the preceding set type record.

+Syntax:

+<pre class="prettyprint">

+%cN = T V; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <4, VV>

+</pre>

+Semantics:

+The integer literal record creates an integer literal constant <code>%cN</code> for

+type <code>T</code>. <code>T</code> must be the type defined by the preceding set type record,

+and an integer type. The literal <code>V</code> can be signed, but must be definable by

+type <code>T</code>.

+Constraints:

+<pre class="prettyprint">

+N == NumFcnConsts &

+T == ConstantsSetType &

+VV == SignRotate(V) &

+IsInteger(T)

+</pre>

+Updates:

+<pre class="prettyprint">

+TypeOf(%cN) = T;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 7> | count 7;

+ 50:4| 3: <7, 8> | @t0 = i8;

+ 53:0| 3: <7, 16> | @t1 = i16;

+ 55:4| 3: <7, 32> | @t2 = i32;

+ 58:6| 3: <7, 64> | @t3 = i64;

+ 62:0| 3: <7, 1> | @t4 = i1;

+ 64:4| 3: <2> | @t5 = void;

+ 66:2| 3: <21, 0, 5> | @t6 = void ();

+ 69:4| 0: <65534> | }

+ ...

+114:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+124:0| 3: <1, 0> | i8:

+126:4| 3: <4, 2> | %c0 = i8 1;

+129:0| 3: <4, 4> | %c1 = i8 2;

+131:4| 3: <1, 1> | i16:

+134:0| 3: <4, 6> | %c2 = i16 3;

+136:4| 3: <4, 8> | %c3 = i16 4;

+139:0| 3: <1, 2> | i32:

+141:4| 3: <4, 10> | %c4 = i32 5;

+144:0| 3: <4, 12> | %c5 = i32 6;

+146:4| 3: <1, 3> | i64:

+149:0| 3: <4, 3> | %c6 = i64 -1;

+151:4| 3: <4, 5> | %c7 = i64 -2;

+154:0| 3: <1, 4> | i1:

+156:4| 3: <4, 3> | %c8 = i1 1;

+159:0| 3: <4, 0> | %c9 = i1 0;

+161:4| 0: <65534> | }

+</pre>

+<h3 id="floating-point-literal">Floating Point Literal</h3>

+The floating point literal record creates a floating point literal for the

+floating point type T defined by the preceding set type record.

+Syntax:

+<pre class="prettyprint">

+%cN = T V; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <6, VV>

+</pre>

+Semantics:

+The floating point literal record creates a floating point literal constant

+<code>%cN</code> for type <code>T</code>. <code>T</code> must the type type defined by the preceding set

+type record, and be a floating point type. The literal <code>V</code> is the floating

+value to be defined. The value <code>VV</code> if the corresponding IEEE unsigned integer

+that defines value <code>V</code>. That is, the literal <code>VV</code> must be a valid IEEE 754

+32-bit (unsigned integer) value if <code>T</code> is <code>float</code>, and a valid IEEE 754

+64-bit (unsigned integer) value if <code>T</code> is <code>double</code>.

+Constraints:

+<pre class="prettyprint">

+N == NumFcnConsts

+T == ConstantsSetType

+IsFloat(T)

+</pre>

+Updates:

+<pre class="prettyprint">

+TypeOf(%cN) = T;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 4> | count 4;

+ 50:4| 3: <3> | @t0 = float;

+ 52:2| 3: <4> | @t1 = double;

+ 54:0| 3: <2> | @t2 = void;

+ 55:6| 3: <21, 0, 2> | @t3 = void ();

+ 59:0| 0: <65534> | }

+ ...

+102:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+112:0| 3: <1, 0> | float:

+114:4| 3: <6, 0> | %c0 = float 0;

+117:0| 3: <6, 1065353216> | %c1 = float 1;

+123:2| 3: <6, 1088421888> | %c2 = float 7;

+130:2| 3: <6, 1090519040> | %c3 = float 8;

+137:2| 3: <3> | %c4 = float undef;

+139:0| 3: <6, 2143289344> | %c5 = float nan;

+146:0| 3: <6, 2139095040> | %c6 = float inf;

+153:0| 3: <6, 4286578688> | %c7 = float -inf;

+160:0| 3: <1, 1> | double:

+162:4| 3: <6, | %c8 = double 1;

+ | 4607182418800017408> |

+174:0| 3: <6, 0> | %c9 = double 0;

+176:4| 3: <6, | %c10 = double 5;

+ | 4617315517961601024> |

+188:0| 3: <6, | %c11 = double 6;

+ | 4618441417868443648> |

+199:4| 3: <6, | %c12 = double nan;

+ | 9221120237041090560> |

+211:0| 3: <6, | %c13 = double inf;

+ | 9218868437227405312> |

+222:4| 3: <6, | %c14 = double -inf;

+ | 18442240474082181120>|

+234:0| 0: <65534> | }

+</pre>

+<h2 id="function-blocks">Function Blocks</h2>

+A function block defines the implementation of a defined <a class="reference internal" href="#link-for-function-address-section">function

+address</a>. The function address it defines is

+based on the position of the corresponding defined function address. The Nth

+defined function address always corresponds to the Nth function block in the

+module block.

+A function implementation contains a list of basic blocks, forming the control

+flow graph. Each basic block contains a list of instructions, and ends with a

+<a class="reference internal" href="#link-for-terminator-instruction-section">terminator instruction</a>

+(e.g. branch).

+Basic blocks are not represented by records. Rather, context is implicit. The

+first basic block begins with the first instruction record in the function

+block. Block boundaries are determined by terminator instructions. The

+instruction that follows a terminator instruction begins a new basic block.

+The first basic block in a function is special in two ways: it is immediately

+executed on entrance to the function, and it is not allowed to have predecessor

+basic blocks (i.e. there can’t be any branches to the entry block of a

+function). Because the entry block has no predecessors, it also can’t have any

+<a class="reference internal" href="#link-for-phi-instruction-section">phi</a> instructions.

+The parameters are implied by the type of the corresponding function

+address. One parameter is defined for each argument of the function <a class="reference internal" href="#link-for-function-type">type

+signature</a> of the corresponding <a class="reference internal" href="#link-for-function-address-section">function

+address</a>.

+The number of basic blocks is defined by the <a class="reference internal" href="#link-for-basic-blocks-count">count

+record</a>. Each <a class="reference internal" href="#link-for-terminator-instruction-section">terminator

+instruction</a> ends the current basic

+block, and the next instruction begins a new basic block. Basic blocks are

+numbered by the order they appear (starting with index 0). Basic block IDs have

+the form <code>%bN</code>, where <code>N</code> corresponds to the position of the basic block

+within the function block.

+Each instruction, within a function block, corresponds to a corresponding PNaCl

+record. The layout of a function block is the (basic block) count record,

+followed by a sequence of instruction records.

+For readability, PNaClAsm introduces basic block IDs. These basic block IDs do

+not correspond to PNaCl records, since basic block boundaries are defined

+implicitly, after terminator instructions. They appear only for readability.

+Operands of instructions are defined using an <a class="reference internal" href="#link-for-absolute-index-section">absolute

+index</a>. This absolute index implicitly encodes

+function addresses, global addresses, parameters, constants, and instructions

+that generate values. The encoding takes advantage of the implied ordering of

+these values in the bitcode file, defining a contiguous sequence of indices for

+each kind of identifier. That is, indices are ordered by putting function

+address identifiers first, followed by global address identifiers, followed by

+parameter identifiers, followed by constant identifiers, and lastly instruction

+value identifiers.

+To save space in the encoded bitcode file, most operands are encoded using a

+<a class="reference internal" href="#link-for-relative-index">relative index</a> value, rather than

+<a class="reference internal" href="#link-for-absolute-index-section">absolute</a>. This

+is done because most instruction operands refer to values defined earlier in the

+(same) basic block. As a result, the relative distance (back) from the next

+value defining instruction is frequently a small number. Small numbers tend to

+require fewer bits when they are converted to bit sequences.

+Note that instructions that can appear in a function block are defined in

+sections <a class="reference internal" href="#link-for-terminator-instruction-section">Terminator Instructions</a>,

+<a class="reference internal" href="#link-for-integer-binary-instructions">Integer Binary Instructions</a>,

+<a class="reference internal" href="#link-for-floating-point-binary-instructions">Floating Point Binary Instructions</a>,

+<a class="reference internal" href="#link-for-memory-creation-and-access-instructions">Memory Creation and Access Instructions</a>,

+<a class="reference internal" href="#link-for-conversion-instructions">Conversion Instructions</a>, <a class="reference internal" href="#link-for-compare-instructions">Comparison Instructions</a>,

+<a class="reference internal" href="#link-for-vector-instructions">Vector Instructions</a>, and

+<a class="reference internal" href="#link-for-other-pnaclasm-instructions">Other Instructions</a>.

+The following subsections define the remaining records that can appear in a

+function block.

+<h3 id="function-enter">Function Enter</h3>

+PNaClAsm defines a function enter block construct. The corresponding record is

+simply an <a class="reference internal" href="#link-for-enter-block-record-section">enter block</a> record, with

+BlockID value <code>12</code>. All context about the defining address is implicit by the

+position of the function block, and the corresponding defining <a class="reference internal" href="#link-for-function-address-section">function

+address</a>. To improve readability, PNaClAsm

+includes the function signature into the syntax rule.

+Syntax:

+<pre class="prettyprint">

+function TR @fN ( T0 %p0, ... , TM %pM ) {

+</pre>

+Record:

+<pre class="prettyprint">

+1: <65535, 12, B>

+</pre>

+Semantics:

+<code>B</code> is the number of bits reserved for abbreviations in the block. If it is

+omitted, 2 is assumed. See <a class="reference internal" href="#link-for-enter-block-record-section">enter</a>

+block records for more details.

+The value of <code>N</code> corresponds to the positional index of the corresponding

+defining function address this block is associated with. <code>M</code> is the number of

+defined parameters (minus one) in the function heading.

+Constraints:

+<pre class="prettyprint">

+N == NumFcnImpls &

+@fN in DefiningFcnIDs &

+TypeOfFcn(@fN) == TypeOf(TypeID(TR (T0, ... , TM)))

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumFcnImpls;

+EnclosingFcnID = @fN;

+NumBasicBlocks = 0;

+ExpectedBlocks = 0;

+NumParams = M;

+for I in [0..M]:

+ TypeOf(%pI) = TypeOf(TypeID(TI));

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 4> | count 4;

+ 50:4| 3: <7, 32> | @t0 = i32;

+ 53:6| 3: <2> | @t1 = void;

+ 55:4| 3: <21, 0, 1> | @t2 = void ();

+ 58:6| 3: <21, 0, 0, 0> | @t3 = i32 (i32);

+ 62:6| 0: <65534> | }

+ ...

+104:0| 1: <65535, 12, 2> | function void @f0() {

+ | | // BlockID = 12

+112:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+114:4| 3: <10> | ret void;

+116:2| 0: <65534> | }

+120:0| 1: <65535, 12, 2> | function i32 @f1(i32 %p0) {

+ | | // BlockID = 12

+128:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+130:4| 3: <10, 1> | ret i32 %p0;

+133:0| 0: <65534> | }

+</pre>

+<h3 id="link-for-basic-blocks-count">Count Record</h3>

+The count record, within a function block, defines the number of basic blocks

+used to define the function implementation. It must be the first record in the

+function block.

+Syntax:

+<pre class="prettyprint">

+ blocks: N; <A>

+%b0:

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <1, N>

+</pre>

+Semantics:

+The count record defines the number <code>N</code> of basic blocks in the implemented

+function.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+ExpectedBasicBlocks == N &

+NumBasicBlocks == 0

+</pre>

+Updates:

+<pre class="prettyprint">

+104:0| 1: <65535, 12, 2> | function void @f0() {

+ | | // BlockID = 12

+112:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+114:4| 3: <10> | ret void;

+116:2| 0: <65534> | }

+120:0| 1: <65535, 12, 2> | function i32 @f1(i32 %p0) {

+ | | // BlockID = 12

+128:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+130:4| 3: <10, 1> | ret i32 %p0;

+133:0| 0: <65534> | }

+</pre>

+<h2 id="terminator-instructions">Terminator Instructions</h2>

+Terminator instructions are instructions that appear in a <a class="reference internal" href="#link-for-function-blocks-section">function

+block</a>, and define the end of the current

+basic block. A terminator instruction indicates which block should be executed

+after the current block is finished. The function block is well formed only if

+the number of terminator instructions, in the function block, corresponds to the

+value defined by the corresponding function basic block <a class="reference internal" href="#link-for-basic-blocks-count">count

+record</a>.

+Note that any branch instruction to label <code>%bN</code>, where <code>N >=

+ExpectedBasicBlocks</code>, is illegal. For ease of readability, this constraint

+hasn’t been put on branch instructions. Rather it is only implied.

+In addition, it must be the case that <code>NumBasicBlocks < ExpectedBasicBlocks</code>,

+and will not be listed as a constraint. Further, if <code>B = NumBasicBlocks + 1</code>

+is the number associated with the next basic block. Label <cite>%bB:</cite> only appears

+if:

+<pre class="prettyprint">

+B < ExpectedBasicBlocks

+</pre>

+That is, the label is omitted only if this terminator instruction is the last

+instruction in the function block.

+<h3 id="return-void-instruction">Return Void Instruction</h3>

+The return void instruction is used to return control from a function back to

+the caller, without returning any value.

+Syntax:

+<pre class="prettyprint">

+ ret void; <A>

+%bB:

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <10>

+</pre>

+Semantics:

+The return void instruction returns control to the calling function.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+B == NumBasicBlocks + 1 &

+ReturnType(TypeOf(EnclosingFcnID)) == void

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumBasicBlocks;

+</pre>

+Examples:

+<pre class="prettyprint">

+104:0| 1: <65535, 12, 2> | function void @f0() {

+ | | // BlockID = 12

+112:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+114:4| 3: <10> | ret void;

+116:2| 0: <65534> | }

+</pre>

+<h3 id="return-value-instruction">Return Value Instruction</h3>

+The return value instruction is used to return control from a function back to

+the caller, including a value. The value must correspond to the return type of

+the enclosing function.

+Syntax:

+<pre class="prettyprint">

+ ret T V; <A>

+%bB:

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <10, VV>

+</pre>

+Semantics:

+The return value instruction returns control to the calling function, returning

+the provided value.

+<code>V</code> is the value to return. Type <code>T</code> must be of the type returned by the

+function. It must also be the type associated with value <code>V</code>.

+The return type <code>T</code> must either be a (non-void) primitive type, or a vector

+type. If the function block is implementing an ordinary function, and the return

+type is an integer type, it must be either <code>i32</code> or <code>i64</code>.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV == RelativeIndex(V) &

+B == NumBasicBlocks + 1 &

+T == TypeOf(V) == ReturnType(TypeOf(EnclosingFcnID))

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumBasicBlocks;

+</pre>

+Examples:

+<pre class="prettyprint">

+120:0| 1: <65535, 12, 2> | function i32 @f1(i32 %p0) {

+ | | // BlockID = 12

+128:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+130:4| 3: <10, 1> | ret i32 %p0;

+</pre>

+<h3 id="unconditional-branch-instruction">Unconditional Branch Instruction</h3>

+The unconditional branch instruction is used to cause control flow to transfer

+to a different basic block of the function.

+Syntax:

+<pre class="prettyprint">

+ br %bN; <A>

+%bB:

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <11, N>

+</pre>

+Semantics:

+The unconditional branch instruction causes control flow to transfer to basic

+block <code>N</code>.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+B == NumBasicBlocks + 1 &

+0 < N &

+N < ExpectedBasicBlocks

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumBasicBlocks;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 88:0| 1: <65535, 12, 2> | function void @f0() {

+ | | // BlockID = 12

+ 96:0| 3: <1, 5> | blocks 5;

+ | | %b0:

+ 98:4| 3: <11, 3> | br label %b3;

+ | | %b1:

+101:0| 3: <11, 4> | br label %b4;

+ | | %b2:

+103:4| 3: <11, 1> | br label %b1;

+ | | %b3:

+106:0| 3: <11, 2> | br label %b2;

+ | | %b4:

+108:4| 3: <10> | ret void;

+110:2| 0: <65534> | }

+</pre>

+<h3 id="conditional-branch-instruction">Conditional Branch Instruction</h3>

+The conditional branch instruction is used to cause control flow to transfer to

+a different basic block of the function, based on a boolean test condition.

+Syntax:

+<pre class="prettyprint">

+ br i1 C, %bT, %bBF; <A>

+%bB:

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <11, T, F, CC>

+</pre>

+Semantics:

+Upon execution of a conditional branch instruction, the i1 (boolean) argument

+<code>C</code> is evaluated. If the value is <code>true</code>, control flows to basic block

+<code>%bT</code>. Otherwise control flows to basic block <code>%bF</code>.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+CC == RelativeIndex(C) &

+B == NumBasicBlocks + 1 &

+0 < T &

+B1 < ExpectedBasicBlocks &

+0 < F &

+B2 < ExpectedBasicBlocks &

+TypeOf(C) == i1

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumBasicBlocks;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 92:0| 1: <65535, 12, 2> | function void @f0() {

+ | | // BlockID = 12

+100:0| 3: <1, 5> | blocks 5;

+102:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+112:0| 3: <1, 1> | i1:

+114:4| 3: <4, 3> | %c0 = i1 1;

+117:0| 3: <4, 0> | %c1 = i1 0;

+119:4| 0: <65534> | }

+ | | %b0:

+120:0| 3: <11, 3> | br label %b3;

+ | | %b1:

+122:4| 3: <11, 2, 4, 2> | br i1 %c0, label %b2, label %b4;

+ | | %b2:

+126:4| 3: <11, 3> | br label %b3;

+ | | %b3:

+129:0| 3: <10> | ret void;

+ | | %b4:

+130:6| 3: <11, 2, 3, 1> | br i1 %c1, label %b2, label %b3;

+134:6| 0: <65534> | }

+</pre>

+<h3 id="unreachable">Unreachable</h3>

+The unreachable instruction has no defined semantics. The instruction is used to

+inform the <a class="reference internal" href="/native-client/overview.html#link-for-pnacl-translator">PNaCl translator</a> that control

+can’t reach this instruction.

+Syntax:

+<pre class="prettyprint">

+ unreachable; <A>

+%bB:

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <15>

+</pre>

+Semantics:

+Directive to the <a class="reference internal" href="/native-client/overview.html#link-for-pnacl-translator">PNaCl translator</a> that

+this instruction is unreachable.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A)

+B == NumBasicBlocks + 1 &

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumBasicBlocks;

+</pre>

+Examples:

+<pre class="prettyprint">

+108:0| 1: <65535, 12, 2> | function void @f0(i32 %p0) {

+ | | // BlockID = 12

+116:0| 3: <1, 5> | blocks 5;

+118:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+128:0| 3: <1, 2> | i1:

+130:4| 3: <4, 3> | %c0 = i1 1;

+133:0| 3: <4, 0> | %c1 = i1 0;

+135:4| 0: <65534> | }

+ | | %b0:

+136:0| 3: <11, 1, 2, 2> | br i1 %c0, label %b1, label %b2;

+ | | %b1:

+140:0| 3: <11, 3, 4, 1> | br i1 %c1, label %b3, label %b4;

+ | | %b2:

+144:0| 3: <15> | unreachable;

+ | | %b3:

+145:6| 3: <15> | unreachable;

+ | | %b4:

+147:4| 3: <10> | ret void;

+149:2| 0: <65534> | }

+</pre>

+<h3 id="switch-instruction">Switch Instruction</h3>

+The switch instruction transfers control flow to one of several different

+places, based on a selector value. It is a generalization of the conditional

+branch instruction.

+Syntax:

+<pre class="prettyprint">

+ switch T V0 {

+ default: br label %bB0;

+ T V1: br label %bB1;

+ ...

+ T VN: br label %bBN;

+ } <A>

+%bB:

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <12, TT, B0, N, (1, 1, VVI, BI | 1 <= i <= N)>

+</pre>

+Semantics:

+The switch instruction transfers control to a basic block in <code>B0</code> through

+<code>BN</code>. Value <code>V</code> is used to conditionally select which block to branch

+to. <code>T</code> is the type of <code>V</code> and <code>V1</code> through <code>VN</code>, and must be an integer

+type. Value <code>V1</code> through <code>VN</code> are integers to compare against <code>V</code>. If

+selector <code>V</code> matches <code>VI</code> (for some <code>I</code>, <code>1 <= I <= N</code>), then the

+instruction branches to block <code>BI</code>. If <code>V</code> is not in <code>V1</code> through <code>VN</code>,

+the instruction branches to block <code>B0</code>.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+B == NumBasicBlocks + 1 &

+TT == TypeID(T) &

+VI == SignRotate(VI) for all I, 1 <= I <= N &

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumBasicBlocks;

+</pre>

+Examples:

+<pre class="prettyprint">

+116:0| 1: <65535, 12, 2> | function void @f0(i32 %p0) {

+ | | // BlockID = 12

+124:0| 3: <1, 6> | blocks 6;

+ | | %b0:

+126:4| 3: <12, 1, 1, 2, 4, 1, 1,| switch i32 %p0 {

+ | 2, 3, 1, 1, 4, 3, 1, | default: br label %b2;

+ | 1, 8, 4, 1, 1, 10, 4>| i32 1: br label %b3;

+ | | i32 2: br label %b3;

+ | | i32 4: br label %b4;

+ | | i32 5: br label %b4;

+ | | }

+ | | %b1:

+143:2| 3: <11, 5> | br label %b5;

+ | | %b2:

+145:6| 3: <11, 5> | br label %b5;

+ | | %b3:

+148:2| 3: <11, 5> | br label %b5;

+ | | %b4:

+150:6| 3: <11, 5> | br label %b5;

+ | | %b5:

+153:2| 3: <10> | ret void;

+155:0| 0: <65534> | }

+156:0| 1: <65535, 12, 2> | function void @f1(i64 %p0) {

+ | | // BlockID = 12

+164:0| 3: <1, 6> | blocks 6;

+ | | %b0:

+166:4| 3: <12, 2, 1, 2, 4, 1, 1,| switch i64 %p0 {

+ | 2, 3, 1, 1, 4, 3, 1, | default: br label %b2;

+ | 1, 8, 4, 1, 1, | i64 1: br label %b3;

+ | 39777555332, 4> | i64 2: br label %b3;

+ | | i64 4: br label %b4;

+ | | i64 19888777666: br label %b4;

+ | | }

+ | | %b1:

+188:4| 3: <11, 5> | br label %b5;

+ | | %b2:

+191:0| 3: <11, 5> | br label %b5;

+ | | %b3:

+193:4| 3: <11, 5> | br label %b5;

+ | | %b4:

+196:0| 3: <11, 5> | br label %b5;

+ | | %b5:

+198:4| 3: <10> | ret void;

+200:2| 0: <65534> | }

+</pre>

+<h2 id="integer-binary-instructions">Integer Binary Instructions</h2>

+Binary instructions are used to do most of the computation in a program. This

+section focuses on binary instructions that operator on integer values, or

+vectors of integer values.

+All binary operations require two operands of the same type, execute an

+operation on them, and produce a value. The value may represent multiple values

+if the type is a vector type. The result value always has the same type as its

+operands.

+Some integer binary operations can be applied to both signed and unsigned

+integers. Others, the sign is significant. In general, if the sign plays a role

+in the instruction, the sign information is encoded into the name of the

+instruction.

+For most binary operations (except some of the logical operations), integer

+type i1 is disallowed.

+<h3 id="integer-add">Integer Add</h3>

+The integer add instruction returns the sum of its two arguments. Both arguments

+and the result must be of the same type. That type must be integer, or an

+integer vector type.

+Syntax:

+<pre class="prettyprint">

+%vN = add T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 0>

+</pre>

+Semantics:

+The integer add instruction returns the sum of its two arguments. Arguments

+<code>V1</code> and <code>V2</code>, and the result <code>%vN</code>, must be of type <code>T</code>. <code>T</code> must be

+an integer type, or an integer vector type. <code>N</code> is defined by the record

+position, defining the corresponding value generated by the instruction.

+The result returned is the mathematical result modulo 2n, where <code>n</code>

+is the bit width of the integer result.

+Because integers are assumed to use a two’s complement representation,

+this instruction is appropriate for both signed and unsigned integers.

+In the add instruction, integer type <code>i1</code> (and a vector of integer type

+<code>i1</code>) is disallowed.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsInteger(UnderlyingType(T)) &

+UnderlyingType(T) != i1 &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <2, 2, 1, 0> | %v0 = add i32 %p0, %p1;

+110:4| 3: <2, 3, 1, 0> | %v1 = add i32 %p0, %v0;

+114:4| 3: <10, 1> | ret i32 %v1;

+117:0| 0: <65534> | }

+</pre>

+<h3 id="integer-subtract">Integer Subtract</h3>

+The integer subtract instruction returns the difference of its two arguments.

+Both arguments and the result must be of the same type. That type must be

+integer, or an integer vector type.

+Note: Since there isn’t a negate instruction, subtraction from constant zero

+should be used to negate values.

+Syntax:

+<pre class="prettyprint">

+%vN = sub T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 1>

+</pre>

+Semantics:

+The integer subtract returns the difference of its two arguments. Arguments

+<code>V1</code> and <code>V2</code>, and the result <code>%vN</code> must be of type <code>T</code>. <code>T</code> must be

+an integer type, or an integer vector type. <code>N</code> is defined by the record

+position, defining the corresponding value generated by the instruction.

+The result returned is the mathematical result modulo 2n, where <code>n</code>

+is the bit width of the integer result.

+Because integers are assumed to use a two’s complement representation,

+this instruction is appropriate for both signed and unsigned integers.

+In the subtract instruction, integer type <code>i1</code> (and a vector of integer type

+<code>i1</code>) is disallowed.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsInteger(UnderlyingType(T)) &

+UnderlyingType(T) != i1 &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <2, 2, 1, 1> | %v0 = sub i32 %p0, %p1;

+110:4| 3: <2, 3, 1, 1> | %v1 = sub i32 %p0, %v0;

+114:4| 3: <10, 1> | ret i32 %v1;

+117:0| 0: <65534> | }

+</pre>

+<h3 id="integer-multiply">Integer Multiply</h3>

+The integer multiply instruction returns the product of its two arguments. Both

+arguments and the result must be of the same type. That type must be integer,

+or an integer based vector type.

+Syntax:

+<pre class="prettyprint">

+&vN = mul T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 2>

+</pre>

+Semantics:

+The integer multiply instruction returns the product of its two

+arguments. Arguments <code>V1</code> and <code>V2</code>, and the result <code>%vN</code>, must be of type

+<code>T</code>. <code>T</code> must be an integer type, or an integer vector type. <code>N</code> is

+defined by the record position, defining the corresponding value generated by

+the instruction.

+The result returned is the mathematical result modulo 2n, where <code>n</code>

+is the bit width of the integer result.

+Because integers are assumed to use a two’s complement representation,

+this instruction is appropriate for both signed and unsigned integers.

+In the subtract instruction, integer type <code>i1</code> (or a vector on integer type

+<code>i1</code>) is disallowed.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsInteger(UnderlyingType(T)) &

+UnderlyingType(T) != i1 &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <2, 2, 1, 2> | %v0 = mul i32 %p0, %p1;

+110:4| 3: <2, 1, 3, 2> | %v1 = mul i32 %v0, %p0;

+114:4| 3: <10, 1> | ret i32 %v1;

+117:0| 0: <65534> | }

+</pre>

+<h3 id="signed-integer-divide">Signed Integer Divide</h3>

+The signed integer divide instruction returns the quotient of its two arguments.

+Both arguments and the result must be of the same type. That type must be

+integer, or an integer vector type.

+Syntax:

+<pre class="prettyprint">

+%vN = sdiv T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 4>

+</pre>

+Semantics:

+The signed integer divide instruction returns the quotient of its two

+arguments. Arguments <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 a integer type, or an integer vector type. <code>N</code> is defined

+by the record position, defining the corresponding value generated by the

+instruction.

+Signed values are assumed. Note that signed and unsigned integer division are

+distinct operations. For unsigned integer division use the unsigned integer

+divide instruction (udiv).

+In the signed integer divide instruction, integer type <code>i1</code> (and a vector of

+integer type <code>i1</code>) is disallowed. Integer division by zero is guaranteed to

+trap.

+Note that overflow can happen with this instruction when dividing the maximum

+negative integer by <code>-1</code>. The behavior for this case is currently undefined.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsInteger(UnderlyingType(T)) &

+UnderlyingType(T) != i1 &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <2, 2, 1, 4> | %v0 = sdiv i32 %p0, %p1;

+110:4| 3: <2, 1, 2, 4> | %v1 = sdiv i32 %v0, %p1;

+114:4| 3: <10, 1> | ret i32 %v1;

+117:0| 0: <65534> | }

+</pre>

+<h3 id="unsigned-integer-divide">Unsigned Integer Divide</h3>

+The unsigned integer divide instruction returns the quotient of its two

+arguments. Both the arguments and the result must be of the same type. That type

+must be integer, or an integer vector type.

+Syntax:

+<pre class="prettyprint">

+%vN = udiv T V1, V2; <a>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, A1, A2, 3>

+</pre>

+Semantics:

+The unsigned integer divide instruction returns the quotient of its two

+arguments. Arguments <code>V1</code> and <code>V2</code>, and the result <code>%vN</code>, must be of type

+<code>T</code>. <code>T</code> must be an integer type, or an integer vector type. <code>N</code> is

+defined by the record position, defining the corresponding value generated by

+the instruction.

+Unsigned integer values are assumed. Note that signed and unsigned integer

+division are distinct operations. For signed integer division use the signed

+integer divide instruction (sdiv).

+In the unsigned integer divide instruction, integer type <code>i1</code> (and a vector of

+integer type <code>i1</code>) is disallowed. Division by zero is guaranteed to trap.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsInteger(UnderlyingType(T)) &

+UnderlyingType(T) != i1 &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <2, 2, 1, 3> | %v0 = udiv i32 %p0, %p1;

+110:4| 3: <2, 1, 2, 3> | %v1 = udiv i32 %v0, %p1;

+114:4| 3: <10, 1> | ret i32 %v1;

+117:0| 0: <65534> | }

+</pre>

+<h3 id="signed-integer-remainder">Signed Integer Remainder</h3>

+The signed integer remainder instruction returns the remainder of the quotient

+of its two arguments. Both arguments and the result must be of the same

+type. That type must be integer, or an integer based vector type.

+Syntax:

+<pre class="prettyprint">

+%vN = srem T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 6>

+</pre>

+Semantics:

+The signed integer remainder instruction returns the remainder of the quotient

+of its two arguments. Arguments <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 a integer type, or an integer vector type. <code>N</code>

+is defined by the record position, defining the corresponding value generated by

+the instruction.

+Signed values are assumed. Note that signed and unsigned integer division are

+distinct operations. For unsigned integer division use the unsigned integer

+remainder instruction (urem).

+In the signed integer remainder instruction, integer type <code>i1</code> (and a vector

+of integer type <code>i1</code>) is disallowed. Division by zero is guaranteed to trap.

+Note that overflow can happen with this instruction when dividing the maximum

+negative integer by <code>-1</code>. The behavior for this case is currently undefined.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsInteger(UnderlyingType(T)) &

+UnderlyingType(T) != i1 &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <2, 2, 1, 6> | %v0 = srem i32 %p0, %p1;

+110:4| 3: <2, 1, 2, 6> | %v1 = srem i32 %v0, %p1;

+114:4| 3: <10, 1> | ret i32 %v1;

+117:0| 0: <65534> | }

+</pre>

+<h3 id="unsigned-integer-remainder-instruction">Unsigned Integer Remainder Instruction</h3>

+The unsigned integer remainder instruction returns the remainder of the quotient

+of its two arguments. Both the arguments and the result must be of the same

+type. The type must be integer, or an integer vector type.

+Syntax:

+<pre class="prettyprint">

+%vN = urem T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, A1, A2, 5>

+</pre>

+Semantics:

+The unsigned integer remainder instruction returns the remainder of the quotient

+of its two arguments. Arguments <code>V1</code> and <code>V2</code>, and the result <code>%vN</code>, must

+be of type <code>T</code>. <code>T</code> must be an integer type, or an integer vector type.

+<code>N</code> is defined by the record position, defining the corresponding value

+generated by the instruction.

+Unsigned values are assumed. Note that signed and unsigned integer division are

+distinct operations. For signed integer division use the remainder instruction

+(srem).

+In the unsigned integer remainder instruction, integer type <code>i1</code> (and a vector

+of integer type <code>i1</code>) is disallowed. Division by zero is guaranteed to trap.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsInteger(UnderlyingType(T)) &

+UnderlyingType(T) != i1 &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <2, 2, 1, 5> | %v0 = urem i32 %p0, %p1;

+110:4| 3: <2, 1, 2, 5> | %v1 = urem i32 %v0, %p1;

+114:4| 3: <10, 1> | ret i32 %v1;

+117:0| 0: <65534> | }

+</pre>

+<h3 id="shift-left">Shift Left</h3>

+The (integer) shift left instruction returns the first operand, shifted to the

+left a specified number of bits with zero fill. The shifted value must be

+integer, or an integer vector type.

+Syntax:

+<pre class="prettyprint">

+%vN = shl T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 7>

+</pre>

+Semantics:

+This instruction performs a shift left operation. Arguments <code>V1</code> and <code>V2</code>

+and the result <code>%vN</code> must be of type <code>T</code>. <code>T</code> must be an integer, or a

+vector of integers. <code>N</code> is defined by the record position, defining the

+corresponding value generated by the instruction.

+<code>V2</code> is assumed to be unsigned. The least significant bits of the result will

+be filled with zero bits after the shift. If <code>V2</code> is (statically or

+dynamically) negative or equal to or larger than the number of bits in

+<code>V1</code>, the result is undefined. If the arguments are vectors, each vector

+element of <code>V1</code> is shifted by the corresponding shift amount in <code>V2</code>.

+In the shift left instruction, integer type <code>i1</code> (and a vector of integer type

+<code>i1</code>) is disallowed.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsInteger(UnderlyingType(T)) &

+UnderlyingType(T) != i1 &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <2, 2, 1, 7> | %v0 = shl i32 %p0, %p1;

+110:4| 3: <2, 1, 2, 7> | %v1 = shl i32 %v0, %p1;

+114:4| 3: <10, 1> | ret i32 %v1;

+117:0| 0: <65534> | }

+</pre>

+<h3 id="logical-shift-right">Logical Shift Right</h3>

+The logical shift right instruction returns the first operand, shifted to the

+right a specified number of bits with zero fill.

+Syntax:

+<pre class="prettyprint">

+%vN = lshr T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 8>

+</pre>

+Semantics:

+This instruction performs a logical shift right operation. Arguments <code>V1</code> and

+<code>V2</code> and the result <code>%vN</code> must be of type <code>T</code>. <code>T</code> must be an integer,

+or a vector of integers. <code>N</code> is defined by the record position, defining the

+corresponding value generated by the instruction.

+<code>V2</code> is assumed to be unsigned. The most significant bits of the result will

+be filled with zero bits after the shift. If <code>V2</code> is (statically or

+dynamically) negative or equal to or larger than the number of bits in <code>V1</code>,

+the result is undefined. If the arguments are vectors, each vector element of

+<code>V1</code> is shifted by the corresponding shift amount in <code>V2</code>.

+In the logical shift right instruction, integer type <code>i1</code> (and a vector of

+integer type <code>i1</code>) is disallowed.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsInteger(UnderlyingType(T)) &

+UnderlyingType(T) != i1 &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <2, 2, 1, 8> | %v0 = lshr i32 %p0, %p1;

+110:4| 3: <2, 1, 2, 8> | %v1 = lshr i32 %v0, %p1;

+114:4| 3: <10, 1> | ret i32 %v1;

+117:0| 0: <65534> | }

+</pre>

+<h3 id="arithmetic-shift-right">Arithmetic Shift Right</h3>

+The arithmetic shift right instruction returns the first operand, shifted to the

+right a specified number of bits with sign extension.

+Syntax:

+<pre class="prettyprint">

+%vN = ashr T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VVA2, 9>

+</pre>

+Semantics:

+This instruction performs an arithmetic shift right operation. Arguments <code>V1</code>

+and <code>V2</code> and and the result <code>%vN</code> must be of type <code>T</code>. <code>T</code> must be an

+integer, or a vector of integers. <code>N</code> is defined by the record position,

+defining the corresponding value generated by the instruction.

+<code>V2</code> is assumed to be unsigned. The most significant bits of the result will

+be filled with the sign bit of <code>V1</code>. If <code>V2</code> is (statically or dynamically)

+negative or equal to or larger than the number of bits in <code>V1</code>, the result is

+undefined. If the arguments are vectors, each vector element of <code>V1</code> is

+shifted by the corresponding shift amount in <code>V2</code>.

+In the arithmetic shift right instruction, integer type <code>i1</code> (and a vector of

+integral type <code>i1</code>) is disallowed.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsInteger(UnderlyingType(T)) &

+UnderlyingType(T) != i1 &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <2, 2, 1, 9> | %v0 = ashr i32 %p0, %p1;

+110:4| 3: <2, 1, 2, 9> | %v1 = ashr i32 %v0, %p1;

+114:4| 3: <10, 1> | ret i32 %v1;

+117:0| 0: <65534> | }

+</pre>

+<h3 id="logical-and">Logical And</h3>

+The and instruction returns the bitwise logical and of its two operands.

+Syntax:

+<pre class="prettyprint">

+%vN = and T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 10>

+</pre>

+Semantics:

+This instruction performs a bitwise logical and of its arguments. Arguments

+<code>V1</code> and <code>V2</code>, and the result <code>%vN</code> must be of type <code>T</code>. <code>T</code> must be

+an integer, or a vector of integers. <code>N</code> is defined by the record position,

+defining the corresponding value generated by the instruction. <code>A</code> is the

+(optional) abbreviation associated with the corresponding record.

+The truth table used for the and instruction is:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">Arg 1</th>

+<th class="head">Arg 2</th>

+<th class="head">Result</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>0</td>

+<td>0</td>

+</tr>

+<tr class="row-odd"><td>0</td>

+<td>1</td>

+<td>0</td>

+</tr>

+<tr class="row-even"><td>1</td>

+<td>0</td>

+</tr>

+<tr class="row-odd"><td>1</td>

+<td>1</td>

+</tr>

+</tbody>

+</table>

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsInteger(UnderlyingType(T))) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <2, 2, 1, 10> | %v0 = and i32 %p0, %p1;

+110:4| 3: <2, 1, 2, 10> | %v1 = and i32 %v0, %p1;

+114:4| 3: <10, 1> | ret i32 %v1;

+117:0| 0: <65534> | }

+</pre>

+<h3 id="logical-or">Logical Or</h3>

+The or instruction returns the bitwise logical inclusive or of its

+two operands.

+Syntax:

+<pre class="prettyprint">

+%vN = or T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 11>

+</pre>

+Semantics:

+This instruction performs a bitwise logical inclusive or of its arguments.

+Arguments <code>V1</code> and <code>V2</code>, and the result <code>%vN</code> must be of type <code>T</code>. <code>T</code>

+must be an integer, or a vector of integers. <code>N</code> is defined by the record

+position, defining the corresponding value generated by the instruction.

+The truth table used for the or instruction is:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">Arg 1</th>

+<th class="head">Arg 2</th>

+<th class="head">Result</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>0</td>

+<td>0</td>

+</tr>

+<tr class="row-odd"><td>0</td>

+<td>1</td>

+</tr>

+<tr class="row-even"><td>1</td>

+<td>0</td>

+<td>1</td>

+</tr>

+<tr class="row-odd"><td>1</td>

+<td>1</td>

+</tr>

+</tbody>

+</table>

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsInteger(UnderlyingType(T))) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <2, 2, 1, 11> | %v0 = or i32 %p0, %p1;

+110:4| 3: <2, 1, 2, 11> | %v1 = or i32 %v0, %p1;

+114:4| 3: <10, 1> | ret i32 %v1;

+117:0| 0: <65534> | }

+</pre>

+<h3 id="logical-xor">Logical Xor</h3>

+The xor instruction returns the bitwise logical exclusive or of its

+two operands.

+Syntax:

+<pre class="prettyprint">

+%vN = xor T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 12>

+</pre>

+Semantics:

+This instruction performs a bitwise logical exclusive or of its arguments.

+Arguments <code>V1</code> and <code>V2</code>, and the result <code>%vN</code> must be of type <code>T</code>. <code>T</code>

+must be an integer, or a vector of integers. <code>N</code> is defined by the record

+position, defining the corresponding value generated by the instruction.

+The truth table used for the xor instruction is:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">Arg 1</th>

+<th class="head">Arg 2</th>

+<th class="head">Result</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>0</td>

+<td>0</td>

+</tr>

+<tr class="row-odd"><td>0</td>

+<td>1</td>

+</tr>

+<tr class="row-even"><td>1</td>

+<td>0</td>

+<td>1</td>

+</tr>

+<tr class="row-odd"><td>1</td>

+<td>1</td>

+<td>0</td>

+</tr>

+</tbody>

+</table>

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+A1 == RelativeIndex(V1) &

+A2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsInteger(UnderlyingType(T))) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <2, 2, 1, 12> | %v0 = xor i32 %p0, %p1;

+110:4| 3: <2, 1, 2, 12> | %v1 = xor i32 %v0, %p1;

+114:4| 3: <10, 1> | ret i32 %v1;

+117:0| 0: <65534> | }

+</pre>

+<h2 id="floating-point-binary-instructions">Floating Point Binary Instructions</h2>

+Floating point binary instructions require two operands of the same type,

+execute an operation on them, and produce a value. The value may represent

+multiple values if the type is a vector type. The result value always has the

+same type as its operands.

+<h3 id="floating-point-add">Floating Point Add</h3>

+The floating point add instruction returns the sum of its two arguments. Both

+arguments and the result must be of the same type. That type must be a floating

+point type, or a vector of a floating point type.

+Syntax:

+<pre class="prettyprint">

+%vN = fadd T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 0>

+</pre>

+Semantics:

+The floating point add instruction returns the sum of its two arguments.

+Arguments <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 a floating point type, or a vector of a floating point type. <code>N</code> is

+defined by the record position, defining the corresponding value generated by

+the instruction.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsFloat(UnderlyingType(T)) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 92:0| 1: <65535, 12, 2> | function

+ | | float @f0(float %p0, float %p1) {

+ | | // BlockID = 12

+100:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+102:4| 3: <2, 2, 1, 0> | %v0 = fadd float %p0, %p1;

+106:4| 3: <2, 3, 1, 0> | %v1 = fadd float %p0, %v0;

+110:4| 3: <10, 1> | ret float %v1;

+113:0| 0: <65534> | }

+</pre>

+<h3 id="floating-point-subtract">Floating Point Subtract</h3>

+The floating point subtract instruction returns the difference of its two

+arguments. Both arguments and the result must be of the same type. That type

+must be a floating point type, or a vector of a floating point type.

+Syntax:

+<pre class="prettyprint">

+%vN = fsub T V1, V2; <a>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 1>

+</pre>

+Semantics:

+The floating point subtract instruction returns the difference of its two

+arguments. Arguments <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 a floating point type, or a vector of a floating point

+type. <code>N</code> is defined by the record position, defining the corresponding value

+generated by the instruction.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsFloat(UnderlyingType(T)) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 92:0| 1: <65535, 12, 2> | function

+ | | float @f0(float %p0, float %p1) {

+ | | // BlockID = 12

+100:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+102:4| 3: <2, 2, 1, 1> | %v0 = fsub float %p0, %p1;

+106:4| 3: <2, 3, 1, 1> | %v1 = fsub float %p0, %v0;

+110:4| 3: <10, 1> | ret float %v1;

+113:0| 0: <65534> | }

+</pre>

+<h3 id="floating-point-multiply">Floating Point Multiply</h3>

+The floating point multiply instruction returns the product of its two

+arguments. Both arguments and the result must be of the same type. That type

+must be a floating point type, or a vector of a floating point type.

+Syntax:

+<pre class="prettyprint">

+&vN = fmul T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 2>

+</pre>

+Semantics:

+The floating point multiply instruction returns the product of its two

+arguments. Arguments <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 a floating point type, or a vector of a floating point

+type. <code>N</code> is defined by the record position, defining the corresponding value

+generated by the instruction.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsFloat(UnderlyingType(T)) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 92:0| 1: <65535, 12, 2> | function

+ | | float @f0(float %p0, float %p1) {

+ | | // BlockID = 12

+100:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+102:4| 3: <2, 2, 1, 2> | %v0 = fmul float %p0, %p1;

+106:4| 3: <2, 3, 1, 2> | %v1 = fmul float %p0, %v0;

+110:4| 3: <10, 1> | ret float %v1;

+113:0| 0: <65534> | }

+</pre>

+<h3 id="floating-point-divide">Floating Point Divide</h3>

+The floating point divide instruction returns the quotient of its two

+arguments. Both arguments and the result must be of the same type. That type

+must be a floating point type, or a vector of a floating point type.

+Syntax:

+<pre class="prettyprint">

+%vN = fdiv T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, V1, V2, 4>

+</pre>

+Semantics:

+The floating point divide instruction returns the quotient of its two

+arguments. Arguments <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 a floating point type, or a vector of a floating point

+type. <code>N</code> is defined by the record position, defining the corresponding value

+generated by the instruction.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV22 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsFloat(UnderlyingType(T)) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 92:0| 1: <65535, 12, 2> | function

+ | | double

+ | | @f0(double %p0, double %p1) {

+ | | // BlockID = 12

+100:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+102:4| 3: <2, 2, 1, 4> | %v0 = fdiv double %p0, %p1;

+106:4| 3: <2, 3, 1, 4> | %v1 = fdiv double %p0, %v0;

+110:4| 3: <10, 1> | ret double %v1;

+113:0| 0: <65534> | }

+</pre>

+<h3 id="floating-point-remainder">Floating Point Remainder</h3>

+The floating point remainder instruction returns the remainder of the quotient

+of its two arguments. Both arguments and the result must be of the same

+type. That type must be a floating point type, or a vector of a floating point

+type.

+Syntax:

+<pre class="prettyprint">

+%vN = frem T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <2, VV1, VV2, 6>

+</pre>

+Semantics:

+The floating point remainder instruction returns the remainder of the quotient

+of its two arguments. Arguments <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 a floating point type, or a vector of a floating

+point type. <code>N</code> is defined by the record position, defining the corresponding

+value generated by the instruction.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+IsFloat(UnderlyingType(T)) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T

+</pre>

+Examples:

+<pre class="prettyprint">

+ 92:0| 1: <65535, 12, 2> | function

+ | | double

+ | | @f0(double %p0, double %p1) {

+ | | // BlockID = 12

+100:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+102:4| 3: <2, 2, 1, 6> | %v0 = frem double %p0, %p1;

+106:4| 3: <2, 3, 1, 6> | %v1 = frem double %p0, %v0;

+110:4| 3: <10, 1> | ret double %v1;

+113:0| 0: <65534> | }

+</pre>

+<h2 id="memory-creation-and-access-instructions">Memory Creation and Access Instructions</h2>

+A key design point of SSA-based representation is how it represents

+memory. In PNaCl bitcode files, no memory locations are in SSA

+form. This makes things very simple.

+<h3 id="alloca-instruction">Alloca Instruction</h3>

+The alloca instruction allocates memory on the stack frame of the

+currently executing function. This memory is automatically released

+when the function returns to its caller.

+Syntax:

+<pre class="prettyprint">

+%vN = alloca i8, i32 S, align V; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <19, SS, VV>

+</pre>

+Semantics:

+The alloca instruction allocates memory on the stack frame of the currently

+executing function. The resulting value is a pointer to the allocated memory

+(i.e. of type i32). <code>S</code> is the number of bytes that are allocated on the

+stack. <code>S</code> must be of integer type i32. <code>V</code> is the alignment of the

+generated stack address.

+Alignment must be a power of 2. See <a class="reference internal" href="#link-for-memory-blocks-and-alignment-section">memory blocks and

+alignment</a> for a more detailed

+discussion on how to define alignment.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+VV == Log2(V+1) &

+SS == RelativeIndex(S) &

+i32 == TypeOf(S) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = i32;

+</pre>

+Examples:

+<pre class="prettyprint">

+112:0| 1: <65535, 12, 2> | function void @f1() {

+ | | // BlockID = 12

+120:0| 3: <1, 1> | blocks 1;

+122:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+132:0| 3: <1, 0> | i32:

+134:4| 3: <4, 4> | %c0 = i32 2;

+137:0| 3: <4, 8> | %c1 = i32 4;

+139:4| 3: <4, 16> | %c2 = i32 8;

+142:0| 0: <65534> | }

+ | | %b0:

+144:0| 3: <19, 3, 1> | %v0 = alloca i8, i32 %c0, align 1;

+147:2| 3: <19, 3, 3> | %v1 = alloca i8, i32 %c1, align 4;

+150:4| 3: <19, 3, 4> | %v2 = alloca i8, i32 %c2, align 8;

+153:6| 3: <10> | ret void;

+155:4| 0: <65534> | }

+</pre>

+<h3 id="load-instruction">Load Instruction</h3>

+The load instruction is used to read from memory.

+Syntax:

+<pre class="prettyprint">

+%vN = load T* P, align V; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <20, PP, VV, TT>

+</pre>

+Semantics:

+The load instruction is used to read from memory. <code>P</code> is the identifier of the

+memory address to read. The type of <code>P</code> must be an <code>i32</code>. <code>T</code> is the type

+of value to read. <code>V</code> is the alignment of the memory address.

+Type <code>T</code> must be a vector, integer, or floating point type. Both <code>float</code> and

+<code>double</code> types are allowed for floating point types. All integer types except

+i1 are allowed.

+Alignment must be a power of 2. See <a class="reference internal" href="#link-for-memory-blocks-and-alignment-section">memory blocks and

+alignment</a> for a more detailed

+discussion on how to define alignment.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+i32 == TypeOf(P) &

+PP == RelativeIndex(P) &

+VV == Log2(V+1) &

+%tTT == TypeID(T) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 4> | count 4;

+ 50:4| 3: <7, 32> | @t0 = i32;

+ 53:6| 3: <2> | @t1 = void;

+ 55:4| 3: <4> | @t2 = double;

+ 57:2| 3: <21, 0, 1, 0> | @t3 = void (i32);

+ 61:2| 0: <65534> | }

+ ...

+ 96:0| 1: <65535, 12, 2> | function void @f0(i32 %p0) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <20, 1, 1, 0> | %v0 = load i32* %p0, align 1;

+110:4| 3: <20, 1, 4, 2> | %v1 = load double* %v0, align 8;

+114:4| 3: <10> | ret void;

+116:2| 0: <65534> | }

+</pre>

+<h3 id="store-instruction">Store Instruction</h3>

+The store instruction is used to write to memory.

+Syntax:

+<pre class="prettyprint">

+store T S, T* P, align V; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <24, PP, SS, VV>

+</pre>

+Semantics:

+The store instruction is used to write to memory. <code>P</code> is the identifier of the

+memory address to write to. The type of <code>P</code> must be an i32 integer. <code>T</code> is

+the type of value to store. <code>S</code> is the value to store, and must be of type

+<code>T</code>. <code>V</code> is the alignment of the memory address. <code>A</code> is the (optional)

+abbreviation index associated with the record.

+Type <code>T</code> must be an integer or floating point type. Both <code>float</code> and

+<code>double</code> types are allowed for floating point types. All integer types except

+i1 are allowed.

+Alignment must be a power of 2. See <a class="reference internal" href="#link-for-memory-blocks-and-alignment-section">memory blocks and

+alignment</a> for a more detailed

+discussion on how to define alignment.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+i32 == TypeOf(P) &

+PP == RelativeIndex(P) &

+VV == Log2(V+1)

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 4> | count 4;

+ 50:4| 3: <7, 32> | @t0 = i32;

+ 53:6| 3: <2> | @t1 = void;

+ 55:4| 3: <4> | @t2 = double;

+ 57:2| 3: <21, 0, 1, 0, 0, 0, 2>| @t3 = void (i32, i32, i32, double);

+ 63:4| 0: <65534> | }

+ ...

+ 96:0| 1: <65535, 12, 2> | function

+ | | void

+ | | @f0(i32 %p0, i32 %p1, i32 %p2,

+ | | double %p3) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+106:4| 3: <24, 4, 3, 1> | store i32 %p1, i32* %p0, align 1;

+110:4| 3: <24, 2, 1, 4> | store double %p3, double* %p2,

+ | | align 8;

+114:4| 3: <10> | ret void;

+116:2| 0: <65534> | }

+</pre>

+<h2 id="conversion-instructions">Conversion Instructions</h2>

+Conversion instructions all take a single operand and a type. The value is

+converted to the corresponding type.

+<h3 id="integer-truncating-instruction">Integer Truncating Instruction</h3>

+The integer truncating instruction takes a value to truncate, and a type

+defining the truncated type. Both types must be integer types, or integer

+vectors with the same number of elements. The bit size of the value must be

+larger than the bit size of the destination type. Equal sized types are not

+allowed.

+Syntax:

+<pre class="prettyprint">

+%vN = trunc T1 V to T2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <3, VV, TT2, 0>

+</pre>

+Semantics:

+The integer truncating instruction takes a value <code>V</code>, and truncates to type

+<code>T2</code>. Both <code>T1</code> and <code>T2</code> must be integer types, or integer vectors with

+the same number of elements. <code>T1</code> has to be wider than <code>T2</code>. If the value

+doesn’t fit in in <code>T2</code>, then the higher order bits are dropped.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+TypeOf(V) == T1 &

+VV == RelativeIndex(V) &

+%tTT2 == TypeID(T2) &

+BitSizeOf(UnderlyingType(T1)) > BitSizeOf(UnderlyingType(T2)) &

+UnderlyingCount(T1) == UnderlyingCount(T2) &

+IsInteger(UnderlyingType(T1)) &

+IsInteger(UnderlyingType(T2)) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T2;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 5> | count 5;

+ 50:4| 3: <7, 32> | @t0 = i32;

+ 53:6| 3: <2> | @t1 = void;

+ 55:4| 3: <7, 16> | @t2 = i16;

+ 58:0| 3: <21, 0, 1, 0> | @t3 = void (i32);

+ 62:0| 3: <7, 8> | @t4 = i8;

+ 64:4| 0: <65534> | }

+ ...

+100:0| 1: <65535, 12, 2> | function void @f0(i32 %p0) {

+ | | // BlockID = 12

+108:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+110:4| 3: <3, 1, 2, 0> | %v0 = trunc i32 %p0 to i16;

+114:4| 3: <3, 1, 4, 0> | %v1 = trunc i16 %v0 to i8;

+118:4| 3: <10> | ret void;

+120:2| 0: <65534> | }

+</pre>

+<h3 id="floating-point-truncating-instruction">Floating Point Truncating Instruction</h3>

+The floating point truncating instruction takes a value to truncate, and a type

+defining the truncated type. Both types must be floating point types, or

+floating point vectors with the same number of elements. The source must be

+<code>double</code> while the destination is <code>float</code>. If the source is a vector, the

+destination must also be vector with the same size as the source.

+Syntax:

+<pre class="prettyprint">

+%vN = fptrunc T1 V to T2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <3, VV, TT2, 7>

+</pre>

+Semantics

+The floating point truncating instruction takes a value <code>V</code>, and truncates to

+type <code>T2</code>. Both <code>T1</code> and <code>T2</code> must be floating point types, or floating

+point vectors with the same number of elements. <code>T1</code> must be defined on

+<code>double</code> while <code>T2</code> is defined on <code>float</code>. If the value can’t fit within

+the destination type <code>T2</code>, the results are undefined.

+Constraints:

+<pre class="prettyprint">

+TypeOf(V) == T1 &

+double == UnderlyingType(T1) &

+float == UnderlyingType(T2) &

+VV == RelativeIndex(V) &

+%tTT2 == TypeID(T2) &

+BitSizeOf(UnderlyingType(T1)) > BitSizeOf(UnderlyingType(T2)) &

+UnderlyingCount(T1) == UnderlyingCount(T2) &

+IsFloat(UnderlyingType(T1)) &

+IsFloat(UnderlyingType(T2)) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T2;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 4> | count 4;

+ 50:4| 3: <3> | @t0 = float;

+ 52:2| 3: <4> | @t1 = double;

+ 54:0| 3: <21, 0, 0, 1> | @t2 = float (double);

+ 58:0| 3: <2> | @t3 = void;

+ 59:6| 0: <65534> | }

+...

+ 92:0| 1: <65535, 12, 2> | function float @f0(double %p0) {

+ | | // BlockID = 12

+100:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+102:4| 3: <3, 1, 0, 7> | %v0 = fptrunc double %p0 to float;

+106:4| 3: <10, 1> | ret float %v0;

+109:0| 0: <65534> | }

+</pre>

+<h3 id="zero-extending-instruction">Zero Extending Instruction</h3>

+The zero extending instruction takes a value to extend, and a type to extend it

+to. Both types must be integer types, or integer vectors with the same number

+of elements. The bit size of the source type must be smaller than the bit size

+of the destination type. Equal sized types are not allowed.

+Syntax:

+<pre class="prettyprint">

+%vN = zext T1 V to T2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <3, VV, TT2, 1>

+</pre>

+Semantics:

+The zero extending instruction takes a value <code>V</code>, and expands it to type

+<code>T2</code>. Both <code>T1</code> and <code>T2</code> must be integer types, or integer vectors with

+the same number of elements. <code>T2</code> must be wider than <code>T1</code>.

+The instruction fills the high order bits of the value with zero bits until it

+reaches the size of the destination type. When zero extending from i1, the

+result will always be either 0 or 1.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+TypeOf(V) == T1 &

+VV == RelativeIndex(V) &

+%tTT2 == TypeID(T2) &

+BitSizeOf(UnderlyingType(T1)) < BitSizeOf(UnderlyingType(T2)) &

+UnderlyingCount(T1) == UnderlyingCount(T2) &

+IsInteger(UnderlyingType(T1)) &

+IsInteger(UnderlyingType(T2)) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T2;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 5> | count 5;

+ 50:4| 3: <7, 64> | @t0 = i64;

+ 53:6| 3: <7, 32> | @t1 = i32;

+ 57:0| 3: <21, 0, 0> | @t2 = i64 ();

+ 60:2| 3: <7, 8> | @t3 = i8;

+ 62:6| 3: <2> | @t4 = void;

+ 64:4| 0: <65534> | }

+ ...

+100:0| 1: <65535, 12, 2> | function i64 @f0() { // BlockID = 12

+108:0| 3: <1, 1> | blocks 1;

+110:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+120:0| 3: <1, 3> | i8:

+122:4| 3: <4, 2> | %c0 = i8 1;

+125:0| 0: <65534> | }

+ | | %b0:

+128:0| 3: <3, 1, 1, 1> | %v0 = zext i8 %c0 to i32;

+132:0| 3: <3, 1, 0, 1> | %v1 = zext i32 %v0 to i64;

+136:0| 3: <10, 1> | ret i64 %v1;

+138:4| 0: <65534> | }

+</pre>

+<h3 id="sign-extending-instruction">Sign Extending Instruction</h3>

+The sign extending instruction takes a value to cast, and a type to extend it

+to. Both types must be integer types, or integral vectors with the same number

+of elements. The bit size of the source type must be smaller than the bit size

+of the destination type. Equal sized types are not allowed.

+Syntax:

+<pre class="prettyprint">

+%vN = sext T1 V to T2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <3, VV, TT2, 2>

+</pre>

+Semantics:

+The sign extending instruction takes a value <code>V</code>, and expands it to type

+<code>T2</code>. Both <code>T1</code> and <code>T2</code> must be integer types, or integer vectors with

+the same number of integers. <code>T2</code> has to be wider than <code>T1</code>.

+When sign extending, the instruction fills the high order bits of the value with

+the (current) high order bit of the value. When sign extending from i1, the

+extension always results in -1 or 0.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+TypeOf(V) == T1 &

+VV == RelativeIndex(V) &

+%tTT2 == TypeID(T2) &

+BitSizeOf(UnderlyingType(T1)) < BitSizeOf(UnderlyingType(T2)) &

+UnderlyingCount(T1) == UnderlyingCount(T2) &

+IsInteger(UnderlyingType(T1)) &

+IsInteger(UnderlyingType(T2)) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T2;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 5> | count 5;

+ 50:4| 3: <7, 64> | @t0 = i64;

+ 53:6| 3: <7, 32> | @t1 = i32;

+ 57:0| 3: <21, 0, 0> | @t2 = i64 ();

+ 60:2| 3: <7, 8> | @t3 = i8;

+ 62:6| 3: <2> | @t4 = void;

+ 64:4| 0: <65534> | }

+ ...

+100:0| 1: <65535, 12, 2> | function i64 @f0() { // BlockID = 12

+108:0| 3: <1, 1> | blocks 1;

+110:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+120:0| 3: <1, 3> | i8:

+122:4| 3: <4, 3> | %c0 = i8 -1;

+125:0| 0: <65534> | }

+ | | %b0:

+128:0| 3: <3, 1, 1, 2> | %v0 = sext i8 %c0 to i32;

+132:0| 3: <3, 1, 0, 2> | %v1 = sext i32 %v0 to i64;

+136:0| 3: <10, 1> | ret i64 %v1;

+138:4| 0: <65534> | }

+</pre>

+<h3 id="floating-point-extending-instruction">Floating Point Extending Instruction</h3>

+The floating point extending instruction takes a value to extend, and a type to

+extend it to. Both types must either be floating point types, or vectors of

+floating point types with the same number of elements. The source value must be

+<code>float</code> while the destination is <code>double</code>. If the source is a vector, the

+destination must also be vector with the same size as the source.

+Syntax:

+<pre class="prettyprint">

+%vN = fpext T1 V to T2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <3, VV, TT2, 8>

+</pre>

+Semantics:

+The floating point extending instruction converts floating point values.

+<code>V</code> is the value to extend, and <code>T2</code> is the type to extend it

+to. Both <code>T1</code> and <code>T2</code> must be floating point types, or floating point

+vector types with the same number of floating point values. <code>T1</code> contains

+<code>float</code> while <code>T2</code> contains <code>double</code>.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+TypeOf(V) == T1 &

+VV == RelativeIndex(V) &

+%tTT2 == TypeID(T2) &

+BitSizeOf(UnderlyingType(T1)) < BitSizeOf(UnderlyingType(T2)) &

+UnderlyingCount(T1) == UnderlyingCount(T2) &

+IsFloat(UnderlyingType(T1)) &

+IsFloat(UnderlyingType(T2)) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T2;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 4> | count 4;

+ 50:4| 3: <4> | @t0 = double;

+ 52:2| 3: <3> | @t1 = float;

+ 54:0| 3: <21, 0, 0, 1> | @t2 = double (float);

+ 58:0| 3: <2> | @t3 = void;

+ 59:6| 0: <65534> | }

+ ...

+ 92:0| 1: <65535, 12, 2> | function double @f0(float %p0) {

+ | | // BlockID = 12

+100:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+102:4| 3: <3, 1, 0, 8> | %v0 = fpext float %p0 to double;

+106:4| 3: <10, 1> | ret double %v0;

+109:0| 0: <65534> | }

+</pre>

+<h3 id="floating-point-to-unsigned-integer-instruction">Floating Point to Unsigned Integer Instruction</h3>

+The floating point to unsigned integer instruction converts floating point

+values to unsigned integers.

+Syntax:

+<pre class="prettyprint">

+%vN = fptoui T1 V to T2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <3, VV, TT2, 3>

+</pre>

+Semantics:

+The floating point to unsigned integer instruction converts floating point

+value(s) in <code>V</code> to its unsigned integer equivalent of type <code>T2</code>. <code>T1</code> must

+be a floating point type, or a floating point vector type. <code>T2</code> must be an

+integer type, or an integer vector type. If either type is a vector type, they

+both must have the same number of elements.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+TypeOf(V) == T1 &

+VV == RelativeIndex(V) &

+%tTT2 == TypeID(T2) &

+UnderlyingCount(T1) == UnderlyingCount(T2) &

+IsFloat(UnderlyingType(T1)) &

+IsInteger(UnderlyingType(T2)) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T2;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 6> | count 6;

+ 50:4| 3: <3> | @t0 = float;

+ 52:2| 3: <4> | @t1 = double;

+ 54:0| 3: <2> | @t2 = void;

+ 55:6| 3: <21, 0, 2, 0, 1> | @t3 = void (float, double);

+ 60:4| 3: <7, 32> | @t4 = i32;

+ 63:6| 3: <7, 16> | @t5 = i16;

+ 66:2| 0: <65534> | }

+ ...

+100:0| 1: <65535, 12, 2> | function

+ | | void @f0(float %p0, double %p1) {

+ | | // BlockID = 12

+108:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+110:4| 3: <3, 2, 4, 3> | %v0 = fptoui float %p0 to i32;

+114:4| 3: <3, 2, 5, 3> | %v1 = fptoui double %p1 to i16;

+118:4| 3: <10> | ret void;

+120:2| 0: <65534> | }

+</pre>

+<h3 id="floating-point-to-signed-integer-instruction">Floating Point to Signed Integer Instruction</h3>

+The floating point to signed integer instruction converts floating point

+values to signed integers.

+Syntax:

+<pre class="prettyprint">

+%vN = fptosi T1 V to T2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <3, VV, TT2, 4>

+</pre>

+Semantics:

+The floating point to signed integer instruction converts floating point

+value(s) in <code>V</code> to its signed integer equivalent of type <code>T2</code>. <code>T1</code> must

+be a floating point type, or a floating point vector type. <code>T2</code> must be an

+integer type, or an integer vector type. If either type is a vector type, they

+both must have the same number of elements.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+TypeOf(V) == T1 &

+VV == RelativeIndex(V) &

+%tTT2 = TypeID(T2) &

+UnderlyingCount(T1) = UnderlyingCount(T2) &

+IsFloat(UnderlyingType(T1)) &

+IsInteger(UnderlyingType(T2)) &

+N = NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T2;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 6> | count 6;

+ 50:4| 3: <3> | @t0 = float;

+ 52:2| 3: <4> | @t1 = double;

+ 54:0| 3: <2> | @t2 = void;

+ 55:6| 3: <21, 0, 2, 0, 1> | @t3 = void (float, double);

+ 60:4| 3: <7, 8> | @t4 = i8;

+ 63:0| 3: <7, 16> | @t5 = i16;

+ 65:4| 0: <65534> | }

+ ...

+100:0| 1: <65535, 12, 2> | function

+ | | void @f0(float %p0, double %p1) {

+ | | // BlockID = 12

+108:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+110:4| 3: <3, 2, 4, 4> | %v0 = fptosi float %p0 to i8;

+114:4| 3: <3, 2, 5, 4> | %v1 = fptosi double %p1 to i16;

+118:4| 3: <10> | ret void;

+120:2| 0: <65534> | }

+</pre>

+<h3 id="unsigned-integer-to-floating-point-instruction">Unsigned Integer to Floating Point Instruction</h3>

+The unsigned integer to floating point instruction converts unsigned integers to

+floating point values.

+Syntax:

+<pre class="prettyprint">

+%vN = uitofp T1 V to T2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <3, VV, TT2, 5>

+</pre>

+Semantics:

+The unsigned integer to floating point instruction converts unsigned integer(s)

+to its floating point equivalent of type <code>T2</code>. <code>T1</code> must be an integer type,

+or a integer vector type. <code>T2</code> must be a floating point type, or a floating

+point vector type. If either type is a vector type, they both must have the same

+number of elements.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+TypeOf(V) == T1 &

+VV == RelativeIndex(V) &

+%tTT2 = TypeID(T2) &

+UnderlyingCount(T1) == UnderlyingCount(T2) &

+IsInteger(UnderlyingType(T1)) &

+IsFloat(UnderlyingType(T2)) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) == T2;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 7> | count 7;

+ 50:4| 3: <7, 32> | @t0 = i32;

+ 53:6| 3: <7, 64> | @t1 = i64;

+ 57:0| 3: <2> | @t2 = void;

+ 58:6| 3: <3> | @t3 = float;

+ 60:4| 3: <21, 0, 2, 0, 1> | @t4 = void (i32, i64);

+ 65:2| 3: <7, 1> | @t5 = i1;

+ 67:6| 3: <4> | @t6 = double;

+ 69:4| 0: <65534> | }

+...

+104:0| 1: <65535, 12, 2> | function void @f0(i32 %p0, i64 %p1) {

+ | | // BlockID = 12

+112:0| 3: <1, 1> | blocks 1;

+114:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+124:0| 3: <1, 5> | i1:

+126:4| 3: <4, 3> | %c0 = i1 1;

+129:0| 0: <65534> | }

+ | | %b0:

+132:0| 3: <3, 1, 6, 5> | %v0 = uitofp i1 %c0 to double;

+136:0| 3: <3, 4, 3, 5> | %v1 = uitofp i32 %p0 to float;

+140:0| 3: <3, 4, 3, 5> | %v2 = uitofp i64 %p1 to float;

+144:0| 3: <10> | ret void;

+145:6| 0: <65534> | }

+</pre>

+<h3 id="signed-integer-to-floating-point-instruction">Signed Integer to Floating Point Instruction</h3>

+The signed integer to floating point instruction converts signed integers to

+floating point values.

+Syntax:

+<pre class="prettyprint">

+%vN = sitofp T1 V to T2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <3, VV, TT2, 6>

+</pre>

+Semantics:

+The signed integer to floating point instruction converts signed integer(s) to

+its floating point equivalent of type <code>T2</code>. <code>T1</code> must be an integer type, or

+a integer vector type. <code>T2</code> must be a floating point type, or a floating point

+vector type. If either type is a vector type, they both must have the same

+number of elements.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+TypeOf(V) == T1 &

+VV == RelativeIndex(V) &

+%tTT2 = TypeID(T2) &

+UnderlyingCount(T1) == UnderlyingCount(T2) &

+IsInteger(UnderlyingType(T1)) &

+IsFloat(UnderlyingType(T2)) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T2;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 7> | count 7;

+ 50:4| 3: <7, 32> | @t0 = i32;

+ 53:6| 3: <7, 64> | @t1 = i64;

+ 57:0| 3: <2> | @t2 = void;

+ 58:6| 3: <3> | @t3 = float;

+ 60:4| 3: <21, 0, 2, 0, 1> | @t4 = void (i32, i64);

+ 65:2| 3: <7, 8> | @t5 = i8;

+ 67:6| 3: <4> | @t6 = double;

+ 69:4| 0: <65534> | }

+ ...

+104:0| 1: <65535, 12, 2> | function void @f0(i32 %p0, i64 %p1) {

+ | | // BlockID = 12

+112:0| 3: <1, 1> | blocks 1;

+114:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+124:0| 3: <1, 5> | i8:

+126:4| 3: <4, 3> | %c0 = i8 -1;

+129:0| 0: <65534> | }

+ | | %b0:

+132:0| 3: <3, 1, 6, 6> | %v0 = sitofp i8 %c0 to double;

+136:0| 3: <3, 4, 3, 6> | %v1 = sitofp i32 %p0 to float;

+140:0| 3: <3, 4, 3, 6> | %v2 = sitofp i64 %p1 to float;

+144:0| 3: <10> | ret void;

+145:6| 0: <65534> | }

+</pre>

+<h3 id="bitcast-instruction">Bitcast Instruction</h3>

+The bitcast instruction converts the type of the value without changing the bit

+contents of the value. The bit size of the type of the value must be the same as

+the bit size of the cast type.

+Syntax:

+<pre class="prettyprint">

+%vN = bitcast T1 V to T2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <3, VV, TT2, 11>

+</pre>

+Semantics:

+The bitcast instruction converts the type of value <code>V</code> to type <code>T2</code>. <code>T1</code>

+and <code>T2</code> must be primitive types or vectors, and define the same number of

+bits.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+TypeOf(V) == T1 &

+VV = RelativeIndex(V) &

+%tTT2 = TypeID(T2) &

+BitSizeOf(T1) == BitSizeOf(T2) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T2;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 6> | count 6;

+ 50:4| 3: <3> | @t0 = float;

+ 52:2| 3: <7, 64> | @t1 = i64;

+ 55:4| 3: <2> | @t2 = void;

+ 57:2| 3: <21, 0, 2, 0, 1> | @t3 = void (float, i64);

+ 62:0| 3: <7, 32> | @t4 = i32;

+ 65:2| 3: <4> | @t5 = double;

+ 67:0| 0: <65534> | }

+ ...

+100:0| 1: <65535, 12, 2> | function void @f0(float %p0, i64 %p1)

+ | | { // BlockID = 12

+108:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+110:4| 3: <3, 2, 4, 11> | %v0 = bitcast float %p0 to i32;

+114:4| 3: <3, 2, 5, 11> | %v1 = bitcast i64 %p1 to double;

+118:4| 3: <10> | ret void;

+120:2| 0: <65534> | }

+</pre>

+<h2 id="comparison-instructions">Comparison Instructions</h2>

+The comparison instructions compare values and generates a boolean (i1) result

+for each pair of compared values. There are different comparison operations for

+integer and floating point values.

+<h3 id="integer-comparison-instructions">Integer Comparison Instructions</h3>

+The integer comparison instruction compares integer values and returns a

+boolean (i1) result for each pair of compared values.

+Syntax:

+<pre class="prettyprint">

+%vN = icmp C T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <9, VV1, VV2, CC>

+</pre>

+Semantics:

+The integer comparison instruction compares integer values and returns a boolean

+(i1) result for each pair of compared values in <code>V1</code> and <code>V2</code>. <code>V1</code> and

+<code>V2</code> must be of type <code>T</code>. <code>T</code> must be an integer type, or an integer

+vector type. Condition code <code>C</code> is the condition applied to all elements in

+<code>V1</code> and <code>V2</code>. Each comparison always yields an i1. If <code>T</code> is a primitive

+type, the resulting type is i1. If <code>T</code> is a vector, then the resulting type is

+a vector of i1 with the same size as <code>T</code>.

+Legal test conditions are:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">C</th>

+<th class="head">CC</th>

+<th class="head">Operator</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>eq</td>

+<td>32</td>

+<td>equal</td>

+</tr>

+<tr class="row-odd"><td>ne</td>

+<td>33</td>

+<td>not equal</td>

+</tr>

+<tr class="row-even"><td>ugt</td>

+<td>34</td>

+<td>unsigned greater than</td>

+</tr>

+<tr class="row-odd"><td>uge</td>

+<td>35</td>

+<td>unsigned greater than or equal</td>

+</tr>

+<tr class="row-even"><td>ult</td>

+<td>36</td>

+<td>unsigned less than</td>

+</tr>

+<tr class="row-odd"><td>ule</td>

+<td>37</td>

+<td>unsigned less than or equal</td>

+</tr>

+<tr class="row-even"><td>sgt</td>

+<td>38</td>

+<td>signed greater than</td>

+</tr>

+<tr class="row-odd"><td>sge</td>

+<td>39</td>

+<td>signed greater than or equal</td>

+</tr>

+<tr class="row-even"><td>slt</td>

+<td>40</td>

+<td>signed less than</td>

+</tr>

+<tr class="row-odd"><td>sle</td>

+<td>41</td>

+<td>signed less than or equal</td>

+</tr>

+</tbody>

+</table>

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+IsInteger(UnderlyingType(T) &

+T == TypeOf(V1) == TypeOf(V2) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+if IsVector(T) then

+ TypeOf(%vN) = <UnderlyingCount(T), i1>

+else

+ TypeOf(%vN) = i1

+endif

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 4> | count 4;

+ 50:4| 3: <7, 32> | @t0 = i32;

+ 53:6| 3: <7, 1> | @t1 = i1;

+ 56:2| 3: <2> | @t2 = void;

+ 58:0| 3: <21, 0, 2> | @t3 = void ();

+ 61:2| 0: <65534> | }

+ ...

+108:0| 1: <65535, 12, 2> | function void @f0() {

+ | | // BlockID = 12

+116:0| 3: <1, 1> | blocks 1;

+118:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+128:0| 3: <1, 0> | i32:

+130:4| 3: <4, 0> | %c0 = i32 0;

+133:0| 3: <4, 2> | %c1 = i32 1;

+135:4| 0: <65534> | }

+ | | %b0:

+136:0| 3: <28, 2, 1, 32> | %v0 = icmp eq i32 %c0, %c1;

+140:6| 3: <28, 3, 2, 33> | %v1 = icmp ne i32 %c0, %c1;

+145:4| 3: <28, 4, 3, 34> | %v2 = icmp ugt i32 %c0, %c1;

+150:2| 3: <28, 5, 4, 36> | %v3 = icmp ult i32 %c0, %c1;

+155:0| 3: <28, 6, 5, 37> | %v4 = icmp ule i32 %c0, %c1;

+159:6| 3: <28, 7, 6, 38> | %v5 = icmp sgt i32 %c0, %c1;

+164:4| 3: <28, 8, 7, 38> | %v6 = icmp sgt i32 %c0, %c1;

+169:2| 3: <28, 9, 8, 39> | %v7 = icmp sge i32 %c0, %c1;

+174:0| 3: <28, 10, 9, 40> | %v8 = icmp slt i32 %c0, %c1;

+178:6| 3: <28, 11, 10, 41> | %v9 = icmp sle i32 %c0, %c1;

+183:4| 3: <10> | ret void;

+185:2| 0: <65534> | }

+</pre>

+<h3 id="floating-point-comparison-instructions">Floating Point Comparison Instructions</h3>

+The floating point comparison instruction compares floating point values and

+returns a boolean (i1) result for each pair of compared values.

+Syntax:

+<pre class="prettyprint">

+%vN = fcmp C T V1, V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <9, VV1, VV2, CC>

+</pre>

+Semantics:

+The floating point comparison instruction compares floating point values and

+returns a boolean (i1) result for each pair of compared values in <code>V1</code> and

+<code>V2</code>. <code>V1</code> and <code>V2</code> must be of type <code>T</code>. <code>T</code> must be a floating point

+type, or a floating point vector type. Condition code <code>C</code> is the condition

+applied to all elements in <code>V1</code> and <code>V2</code>. Each comparison always yields an

+i1. If <code>T</code> is a primitive type, the resulting type is i1. If <code>T</code> is a

+vector, then the resulting type is a vector of i1 with the same size as <code>T</code>.

+Legal test conditions are:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">C</th>

+<th class="head">CC</th>

+<th class="head">Operator</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>false</td>

+<td>0</td>

+<td>Always false</td>

+</tr>

+<tr class="row-odd"><td>oeq</td>

+<td>1</td>

+<td>Ordered and equal</td>

+</tr>

+<tr class="row-even"><td>ogt</td>

+<td>2</td>

+<td>Ordered and greater than</td>

+</tr>

+<tr class="row-odd"><td>oge</td>

+<td>3</td>

+<td>Ordered and greater than or equal</td>

+</tr>

+<tr class="row-even"><td>olt</td>

+<td>4</td>

+<td>Ordered and less than</td>

+</tr>

+<tr class="row-odd"><td>ole</td>

+<td>5</td>

+<td>Ordered and less than or equal</td>

+</tr>

+<tr class="row-even"><td>one</td>

+<td>6</td>

+<td>Ordered and not equal</td>

+</tr>

+<tr class="row-odd"><td>ord</td>

+<td>7</td>

+<td>Ordered (no NaNs)</td>

+</tr>

+<tr class="row-even"><td>uno</td>

+<td>8</td>

+<td>Unordered (either NaNs)</td>

+</tr>

+<tr class="row-odd"><td>ueq</td>

+<td>9</td>

+<td>Unordered or equal</td>

+</tr>

+<tr class="row-even"><td>ugt</td>

+<td>10</td>

+<td>Unordered or greater than</td>

+</tr>

+<tr class="row-odd"><td>uge</td>

+<td>11</td>

+<td>Unordered or greater than or equal</td>

+</tr>

+<tr class="row-even"><td>ult</td>

+<td>12</td>

+<td>Unordered or less than</td>

+</tr>

+<tr class="row-odd"><td>ule</td>

+<td>13</td>

+<td>Unordered or less than or equal</td>

+</tr>

+<tr class="row-even"><td>une</td>

+<td>14</td>

+<td>Unordered or not equal</td>

+</tr>

+<tr class="row-odd"><td>true</td>

+<td>15</td>

+<td>Always true</td>

+</tr>

+</tbody>

+</table>

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+IsFloat(UnderlyingType(T) &

+T == TypeOf(V1) == TypeOf(V2) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+if IsVector(T) then

+ TypeOf(%vN) = <UnderlyingCount(T), i1>

+else

+ TypeOf(%vN) = i1

+endif

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 4> | count 4;

+ 50:4| 3: <3> | @t0 = float;

+ 52:2| 3: <7, 1> | @t1 = i1;

+ 54:6| 3: <2> | @t2 = void;

+ 56:4| 3: <21, 0, 2> | @t3 = void ();

+ 59:6| 0: <65534> | }

+ ...

+108:0| 1: <65535, 12, 2> | function void @f0() {

+ | | // BlockID = 12

+116:0| 3: <1, 1> | blocks 1;

+118:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+128:0| 3: <1, 0> | float:

+130:4| 3: <6, 0> | %c0 = float 0;

+133:0| 3: <6, 1065353216> | %c1 = float 1;

+139:2| 0: <65534> | }

+ | | %b0:

+140:0| 3: <28, 2, 1, 0> | %v0 = fcmp false float %c0, %c1;

+144:0| 3: <28, 3, 2, 1> | %v1 = fcmp oeq float %c0, %c1;

+148:0| 3: <28, 4, 3, 2> | %v2 = fcmp ogt float %c0, %c1;

+152:0| 3: <28, 5, 4, 3> | %v3 = fcmp oge float %c0, %c1;

+156:0| 3: <28, 6, 5, 4> | %v4 = fcmp olt float %c0, %c1;

+160:0| 3: <28, 7, 6, 5> | %v5 = fcmp ole float %c0, %c1;

+164:0| 3: <28, 8, 7, 6> | %v6 = fcmp one float %c0, %c1;

+168:0| 3: <28, 9, 8, 7> | %v7 = fcmp ord float %c0, %c1;

+172:0| 3: <28, 10, 9, 9> | %v8 = fcmp ueq float %c0, %c1;

+176:0| 3: <28, 11, 10, 10> | %v9 = fcmp ugt float %c0, %c1;

+180:0| 3: <28, 12, 11, 11> | %v10 = fcmp uge float %c0, %c1;

+184:0| 3: <28, 13, 12, 12> | %v11 = fcmp ult float %c0, %c1;

+188:0| 3: <28, 14, 13, 13> | %v12 = fcmp ule float %c0, %c1;

+192:0| 3: <28, 15, 14, 14> | %v13 = fcmp une float %c0, %c1;

+196:0| 3: <28, 16, 15, 8> | %v14 = fcmp uno float %c0, %c1;

+200:0| 3: <28, 17, 16, 15> | %v15 = fcmp true float %c0, %c1;

+204:0| 3: <10> | ret void;

+205:6| 0: <65534> | }

+208:0|0: <65534> |}

+</pre>

+<h2 id="vector-instructions">Vector Instructions</h2>

+PNaClAsm supports several instructions that process vectors. This includes the

+<a class="reference internal" href="#link-for-integer-binary-instructions">integer</a> and <a class="reference internal" href="#link-for-floating-point-binary-instructions">floating

+point</a> binary instructions as well

+as <a class="reference internal" href="#link-for-compare-instructions">compare</a> instructions. These

+instructions work with vectors and generate resulting (new) vectors. This

+section introduces the instructions to construct vectors and extract results.

+<h3 id="insert-element-instruction">Insert Element Instruction</h3>

+The insert element instruction inserts a scalar value into a vector at a

+specified index. The insert element instruction takes an existing vector and

+puts a scalar value in one of the elements of the vector.

+The insert element instruction can be used to construct a vector, one element

+at a time. At first glance, it may appear that one can’t construct a vector,

+since the insert element instruction needs a vector to insert elements into.

+The key to understanding vector construction is understand that one can create

+an <a class="reference internal" href="#link-for-undefined-literal">undefined</a> vector literal. Using that

+constant as a starting point, one can built up the wanted vector by a sequence

+of insert element instructions.

+Syntax:

+<pre class="prettyprint">

+%vN = insertelement TV V, TE E, i32 I; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <7, VV, EE, II>

+</pre>

+Semantics:

+The insert element instruction inserts scalar value <code>E</code> into index <code>I</code> of

+vector <code>V</code>. <code>%vN</code> holds the updated vector. Type <code>TV</code> is the type of

+vector. It is also the type of updated vector <code>%vN</code>. Type <code>TE</code> is the type

+of scalar value <code>E</code> and must be the element type of vector <code>V</code>. <code>I</code> must

+be an <a class="reference internal" href="#link-for-integer-literal">i32 literal</a>.

+If <code>I</code> exceeds the length of <code>V</code>, the result is undefined.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+IsVector(TV) &

+TypeOf(V) == TV &

+UnderlyingType(TV) == TE &

+TypeOf(I) == i32 &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = TV;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 5> | count 5;

+ 50:4| 3: <7, 1> | @t0 = i1;

+ 53:0| 3: <12, 4, 0> | @t1 = <4 x i1>;

+ 56:2| 3: <7, 32> | @t2 = i32;

+ 59:4| 3: <2> | @t3 = void;

+ 61:2| 3: <21, 0, 3> | @t4 = void ();

+ 64:4| 0: <65534> | }

+ ...

+116:0| 1: <65535, 12, 2> | function void @f0() {

+ | | // BlockID = 12

+124:0| 3: <1, 1> | blocks 1;

+126:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+136:0| 3: <1, 0> | i1:

+138:4| 3: <4, 0> | %c0 = i1 0;

+141:0| 3: <4, 3> | %c1 = i1 1;

+143:4| 3: <1, 1> | <4 x i1>:

+146:0| 3: <3> | %c2 = <4 x i1> undef;

+147:6| 3: <1, 2> | i32:

+150:2| 3: <4, 0> | %c3 = i32 0;

+152:6| 3: <4, 2> | %c4 = i32 1;

+155:2| 3: <4, 4> | %c5 = i32 2;

+157:6| 3: <4, 6> | %c6 = i32 3;

+160:2| 0: <65534> | }

+ | | %b0:

+164:0| 3: <7, 5, 7, 4> | %v0 = insertelement <4 x i1> %c2,

+ | | i1 %c0, i32 %c3;

+168:0| 3: <7, 1, 7, 4> | %v1 = insertelement <4 x i1> %v0,

+ | | i1 %c1, i32 %c4;

+172:0| 3: <7, 1, 9, 4> | %v2 = insertelement <4 x i1> %v1,

+ | | i1 %c0, i32 %c5;

+176:0| 3: <7, 1, 9, 4> | %v3 = insertelement <4 x i1> %v2,

+ | | i1 %c1, i32 %c6;

+180:0| 3: <10> | ret void;

+181:6| 0: <65534> | }

+</pre>

+<h3 id="extract-element-instruction">Extract Element Instruction</h3>

+The extract element instruction extracts a single scalar value from a vector

+at a specified index.

+Syntax:

+<pre class="prettyprint">

+%vN = extractelement TV V, i32 I; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <6, VV, II>

+</pre>

+Semantics:

+The extract element instruction extracts the scalar value at index <code>I</code> from

+vector <code>V</code>. The extracted value is assigned to <code>%vN</code>. Type <code>TV</code> is the

+type of vector <code>V</code>. <code>I</code> must be an <a class="reference internal" href="#link-for-integer-literal">i32

+literal</a>. The type of <code>vN</code> must be the element type

+of vector <code>V</code>.

+If <code>I</code> exceeds the length of <code>V</code>, the result is undefined.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+IsVector(TV) &

+TypeOf(V) == TV &

+TypeOf(I) == i32 &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = UnderlyingType(TV);

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function void @f0(<4 x i32> %p0) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+106:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+116:0| 3: <1, 0> | i32:

+118:4| 3: <4, 0> | %c0 = i32 0;

+121:0| 0: <65534> | }

+ | | %b0:

+124:0| 3: <6, 2, 1> | %v0 =

+ | | extractelement <4 x i32> %p0,

+ | | i32 %c0;

+127:2| 3: <10> | ret void;

+129:0| 0: <65534> | }

+</pre>

+<h2 id="other-instructions">Other Instructions</h2>

+This section defines miscellaneous instructions which defy better

+classification.

+<h3 id="forward-type-declaration">Forward Type Declaration</h3>

+The forward type declaration exists to deal with the fact that all instruction

+values must have a type associated with them before they are used. For some

+simple functions one can easily topologically sort instructions so that

+instruction values are defined before they are used. However, if the

+implementation contains loops, the loop induced values can’t be defined before

+they are used.

+The solution is to forward declare the type of an instruction value. One could

+forward declare the types of all instructions at the beginning of the function

+block. However, this would make the corresponding file size considerably

+larger. Rather, one should only generate these forward type declarations

+sparingly and only when needed.

+Syntax:

+<pre class="prettyprint">

+declare T %vN; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <43, N, TT>

+</pre>

+Semantics:

+The forward declare type declaration defines the type to be associated with a

+(not yet defined) instruction value <code>%vN</code>. <code>T</code> is the type of the value

+generated by the <code>Nth</code> value generating instruction in the function block.

+Note: It is an error to define the type of <code>%vN</code> with a different type than

+will be generated by the <code>Nth</code> value generating instruction in the function

+block.

+Also note that this construct is a declaration and not considered an

+instruction, even though it appears in the list of instruction records. Hence,

+they may appear before and between <a class="reference internal" href="#link-for-phi-instruction-section">phi</a>

+instructions in a basic block.

+Constraints:

+<pre class="prettyprint">

+AA = AbbrevIndex(A) &

+TT = TypeID(T)

+</pre>

+Updates:

+<pre class="prettyprint">

+TypeOf(%vN) = T;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 4> | count 4;

+ 50:4| 3: <7, 32> | @t0 = i32;

+ 53:6| 3: <2> | @t1 = void;

+ 55:4| 3: <7, 1> | @t2 = i1;

+ 58:0| 3: <21, 0, 1, 0> | @t3 = void (i32);

+ 62:0| 0: <65534> | }

+ ...

+108:0| 1: <65535, 12, 2> | function void @f0(i32 %p0) {

+ | | // BlockID = 12

+116:0| 3: <1, 7> | blocks 7;

+118:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+128:0| 3: <1, 2> | i1:

+130:4| 3: <4, 3> | %c0 = i1 1;

+133:0| 0: <65534> | }

+ | | %b0:

+136:0| 3: <11, 4> | br label %b4;

+ | | %b1:

+138:4| 3: <43, 6, 0> | declare i32 %v3;

+142:4| 3: <2, 2, 4294967293, 0> | %v0 = add i32 %p0, %v3;

+151:0| 3: <11, 6> | br label %b6;

+ | | %b2:

+153:4| 3: <43, 7, 0> | declare i32 %v4;

+157:4| 3: <2, 3, 4294967293, 0> | %v1 = add i32 %p0, %v4;

+166:0| 3: <11, 6> | br label %b6;

+ | | %b3:

+168:4| 3: <2, 4, 4294967295, 0> | %v2 = add i32 %p0, %v3;

+177:0| 3: <11, 6> | br label %b6;

+ | | %b4:

+179:4| 3: <2, 5, 5, 0> | %v3 = add i32 %p0, %p0;

+183:4| 3: <11, 1, 5, 5> | br i1 %c0, label %b1, label %b5;

+ | | %b5:

+187:4| 3: <2, 1, 6, 0> | %v4 = add i32 %v3, %p0;

+191:4| 3: <11, 2, 3, 6> | br i1 %c0, label %b2, label %b3;

+ | | %b6:

+195:4| 3: <10> | ret void;

+197:2| 0: <65534> | }

+</pre>

+<h3 id="phi-instruction">Phi Instruction</h3>

+The phi instruction is used to implement phi nodes in the SSA graph

+representing the function. Phi instructions can only appear at the beginning of

+a basic block. There must be no non-phi instructions (other than forward type

+declarations) between the start of the basic block and the phi instruction.

+To clarify the origin of each incoming value, the incoming value is associated

+with the incoming edge from the corresponding predecessor block that the

+incoming value comes from.

+Syntax:

+<pre class="prettyprint">

+%vN = phi T [V1, %bB1], ... , [VM, %bBM]; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <16, TT, VV1, B1, ..., VVM, BM>

+</pre>

+Semantics:

+The phi instruction is used to implement phi nodes in the SSA graph representing

+the function. <code>%vN</code> is the resulting value of the corresponding phi

+node. <code>T</code> is the type of the phi node. Values <code>V1</code> through <code>VM</code> are the

+reaching definitions for the phi node while <code>%bB1</code> through <code>%bBM</code> are the

+corresponding predecessor blocks. Each <code>VI</code> reaches via the incoming

+predecessor edge from block <code>%bBI</code> (for 1 <= I <= M). Type <code>T</code> must be the

+type associated with each <code>VI</code>.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+M > 1 &

+TT == TypeID(T) &

+T = TypeOf(VI) for all I, 1 <= I <= M &

+BI < ExpectedBasicBlocks for all I, 1 <= I <= M &

+VVI = SignRotate(RelativeIndex(VI)) for all I, 1 <= I <= M &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 4> | count 4;

+ 50:4| 3: <7, 32> | @t0 = i32;

+ 53:6| 3: <2> | @t1 = void;

+ 55:4| 3: <21, 0, 1> | @t2 = void ();

+ 58:6| 3: <7, 1> | @t3 = i1;

+ 61:2| 0: <65534> | }

+ ...

+112:0| 1: <65535, 12, 2> | function void @f0() {

+ | | // BlockID = 12

+120:0| 3: <1, 4> | blocks 4;

+122:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+132:0| 3: <1, 0> | i32:

+134:4| 3: <4, 2> | %c0 = i32 1;

+137:0| 3: <1, 3> | i1:

+139:4| 3: <4, 0> | %c1 = i1 0;

+142:0| 0: <65534> | }

+ | | %b0:

+144:0| 3: <11, 1, 2, 1> | br i1 %c1, label %b1, label %b2;

+ | | %b1:

+148:0| 3: <2, 2, 2, 0> | %v0 = add i32 %c0, %c0;

+152:0| 3: <2, 3, 3, 1> | %v1 = sub i32 %c0, %c0;

+156:0| 3: <11, 3> | br label %b3;

+ | | %b2:

+158:4| 3: <2, 4, 4, 2> | %v2 = mul i32 %c0, %c0;

+162:4| 3: <2, 5, 5, 3> | %v3 = udiv i32 %c0, %c0;

+166:4| 3: <11, 3> | br label %b3;

+ | | %b3:

+169:0| 3: <16, 0, 8, 1, 4, 2> | %v4 = phi i32 [%v0, %b1],

+ | | [%v2, %b2];

+174:4| 3: <16, 0, 8, 1, 4, 2> | %v5 = phi i32 [%v1, %b1],

+ | | [%v3, %b2];

+180:0| 3: <10> | ret void;

+181:6| 0: <65534> | }

+</pre>

+<h3 id="select-instruction">Select Instruction</h3>

+The select instruction is used to choose between pairs of values, based on a

+condition, without PNaClAsm-level branching.

+Syntax:

+<pre class="prettyprint">

+%vN = select CT C, T V1, T V2; <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <29, VV1, VV2, CC>

+</pre>

+Semantics:

+The select instruction chooses pairs of values <code>V1</code> and <code>V2</code>, based on

+condition value <code>C</code>. The type <code>CT</code> of value <code>C</code> must either be an i1, or

+a vector of type i1. The type of values <code>V1</code> and <code>V2</code> must be of type

+<code>T</code>. Type <code>T</code> must either be a primitive type, or a vector of a primitive

+type.

+Both <code>CT</code> and <code>T</code> must be primitive types, or both must be vector types of

+the same size. When the contents of <code>C</code> is 1, the corresponding value from

+<code>V1</code> will be chosen. Otherwise the corresponding value from <code>V2</code> will be

+chosen.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+CC == RelativeIndex(C) &

+VV1 == RelativeIndex(V1) &

+VV2 == RelativeIndex(V2) &

+T == TypeOf(V1) == TypeOf(V2) &

+UnderlyingType(CT) == i1 &

+IsInteger(UnderlyingType(T)) or IsFloat(UnderlyingType(T)) &

+UnderlyingCount(C) == UnderlyingCount(T) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = T;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 96:0| 1: <65535, 12, 2> | function i32 @f0(i32 %p0, i32 %p1) {

+ | | // BlockID = 12

+104:0| 3: <1, 1> | blocks 1;

+106:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+116:0| 3: <1, 2> | i1:

+118:4| 3: <4, 3> | %c0 = i1 1;

+121:0| 0: <65534> | }

+ | | %b0:

+124:0| 3: <29, 3, 2, 1> | %v0 = select i1 %c0, i32 %p0,

+ | | i32 %p1;

+128:0| 3: <10, 1> | ret i32 %v0;

+130:4| 0: <65534> | }

+</pre>

+<h3 id="call-instructions">Call Instructions</h3>

+The call instruction does a function call. The call instruction is used to

+cause control flow to transfer to a specified routine, with its incoming

+arguments bound to the specified values. When a return instruction in the called

+function is reached, control flow continues with the instruction after the

+function call. If the call is to a function, the returned value is the value

+generated by the call instruction. Otherwise no result is defined by the call.

+If the tail flag is associated with the call instruction, then the <a class="reference internal" href="/native-client/overview.html#link-for-pnacl-translator">PNaCl

+translator</a> is free to perform tail call

+optimization. That is, the tail flag is a hint that may be ignored by the

+PNaCl translator.

+There are two kinds of calls: direct and indirect. A direct call calls a

+defined <a class="reference internal" href="#link-for-function-address-section">function address</a> (i.e. a

+reference to a bitcode ID of the form <code>%fF</code>). All other calls are indirect.

+<h4 id="direct-procedure-call">Direct Procedure Call</h4>

+The direct procedure call calls a defined <a class="reference internal" href="#link-for-function-address-section">function

+address</a> whose <a class="reference internal" href="#link-for-function-type">type

+signature</a> returns type void.

+Syntax:

+<pre class="prettyprint">

+TAIL call void @fF (T1 A1, ... , TN AN); <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <34, CC, F, AA1, ... , AAN>

+</pre>

+Semantics:

+The direct procedure call calls a define function address <code>%fF</code> whose type

+signature return type is void. The arguments <code>A1</code> through <code>AN</code> are passed in

+the order specified. The type of argument <code>AI</code> must be type <code>TI</code> (for all I,

+1 <=I <= N). Flag <code>TAIL</code> is optional. If it is included, it must be the

+literal <code>tail</code>.

+The types of the arguments must match the corresponding types of the function

+signature associated with <code>%fF</code>. The return type of <code>%f</code> must be void.

+TAIL is encoded into calling convention value <code>CC</code> as follows:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">TAIL</th>

+<th class="head">CC</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>“”</td>

+<td>0</td>

+</tr>

+<tr class="row-odd"><td>“tail”</td>

+<td>1</td>

+</tr>

+</tbody>

+</table>

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+N >= 0 &

+TypeOfFcn(%fF) == void (T1, ... , TN) &

+TypeOf(AI) == TI for all I, 1 <= I <= N

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 72:0| 3: <8, 3, 0, 1, 0> | declare external

+ | | void @f0(i32, i64, i32);

+ ...

+116:0| 1: <65535, 12, 2> | function void @f1(i32 %p0) {

+ | | // BlockID = 12

+124:0| 3: <1, 1> | blocks 1;

+126:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+136:0| 3: <1, 2> | i64:

+138:4| 3: <4, 2> | %c0 = i64 1;

+141:0| 0: <65534> | }

+ | | %b0:

+144:0| 3: <34, 0, 4, 2, 1, 2> | call void

+ | | @f0(i32 %p0, i64 %c0, i32 %p0);

+150:2| 3: <10> | ret void;

+152:0| 0: <65534> | }

+</pre>

+<h4 id="direct-function-call">Direct Function Call</h4>

+The direct function call calls a defined function address whose type signature

+returns a value.

+Syntax:

+<pre class="prettyprint">

+%vN = TAIL call RT %fF (T1 A1, ... , TM AM); <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <34, CC, F, AA1, ... , AAM>

+</pre>

+Semantics:

+The direct function call calls a defined function address <code>%fF</code> whose type

+signature returned is not type void. The arguments <code>A1</code> through <code>AM</code> are

+passed in the order specified. The type of argument <code>AI</code> must be type <code>TI</code>

+(for all I, 1 <= I <= N). Flag <code>TAIL</code> is optional. If it is included, it must

+be the literal <code>tail</code>.

+The types of the arguments must match the corresponding types of the function

+signature associated with <code>%fF</code>. The return type must match <code>RT</code>.

+Each parameter type <code>TI</code>, and return type <code>RT</code>, must either be a primitive

+type, or a vector type. If the parameter type is an integer type, it must

+either be i32 or i64.

+TAIL is encoded into calling convention value <code>CC</code> as follows:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">TAIL</th>

+<th class="head">CC</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>“”</td>

+<td>0</td>

+</tr>

+<tr class="row-odd"><td>“tail”</td>

+<td>1</td>

+</tr>

+</tbody>

+</table>

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+N >= 0 &

+TypeOfFcn(%fF) == RT (T1, ... , TN) &

+TypeOf(AI) == TI for all I, 1 <= I <= M &

+IsFcnArgType(TI) for all I, 1 <= I <= M &

+IsFcnArgType(RT) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = RT;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 72:0| 3: <8, 2, 0, 1, 0> | declare external

+ | | i32 @f0(i32, i64, i32);

+ ...

+116:0| 1: <65535, 12, 2> | function i32 @f1(i32 %p0) {

+ | | // BlockID = 12

+124:0| 3: <1, 1> | blocks 1;

+126:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+136:0| 3: <1, 1> | i64:

+138:4| 3: <4, 2> | %c0 = i64 1;

+141:0| 0: <65534> | }

+ | | %b0:

+144:0| 3: <34, 0, 4, 2, 1, 2> | %v0 = call i32

+ | | @f0(i32 %p0, i64 %c0, i32 %p0);

+150:2| 3: <34, 1, 4, 1> | %v1 = tail call i32 @f1(i32 %v0);

+155:0| 3: <10, 2> | ret i32 %v0;

+157:4| 0: <65534> | }

+</pre>

+<h4 id="indirect-procedure-call">Indirect Procedure Call</h4>

+The indirect procedure call calls a function using an indirect function address,

+and whose type signature is assumed to return type void. It is different from

+the direct procedure call because we can’t use the type signature of the

+corresponding direct function address to type check the construct.

+Syntax:

+<pre class="prettyprint">

+TAIL call void V (T1 A1, ... , TN AN); <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <44, CC, TV, VV, AA1, ... , AAN>

+</pre>

+Semantics:

+The indirect call procedure calls a function using value <code>V</code> that is an

+indirect function address, and whose type signature is assumed to return type

+void. The arguments <code>A1</code> through <code>AN</code> are passed in the order

+specified. The type of argument <code>AI</code> must be type <code>TI</code> (for all I, 1 <= I <=

+N). Flag <code>TAIL</code> is optional. If it is included, it must be the literal

+<code>tail</code>.

+Each parameter type <code>TI</code> (1 <= I <= N) must either be a primitive type, or a

+vector type. If the parameter type is an integer type, it must either be i32

+or i64.

+TAIL is encoded into calling convention value <code>CC</code> as follows:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">TAIL</th>

+<th class="head">CC</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>“”</td>

+<td>0</td>

+</tr>

+<tr class="row-odd"><td>“tail”</td>

+<td>1</td>

+</tr>

+</tbody>

+</table>

+The type signature of the called procedure is assumed to be:

+<pre class="prettyprint">

+void (T1, ... , TN)

+</pre>

+It isn’t necessary to define this type in the <a class="reference internal" href="#link-for-types-block-section">types

+block</a>, since the type is inferred rather than

+used.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+N >= 0 &

+TV = TypeID(void) &

+AbsoluteIndex(V) >= NumFuncAddresses &

+TypeOf(AI) == TI for all I, 1 <= I <= N &

+IsFcnArgType(TI) for all I, 1 <= I <= N

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 3> | count 3;

+ 50:4| 3: <2> | @t0 = void;

+ 52:2| 3: <7, 32> | @t1 = i32;

+ 55:4| 3: <21, 0, 0, 1> | @t2 = void (i32);

+ 59:4| 0: <65534> | }

+ ...

+ 92:0| 1: <65535, 12, 2> | function void @f0(i32 %p0) {

+ | | // BlockID = 12

+100:0| 3: <1, 1> | blocks 1;

+102:4| 1: <65535, 11, 2> | constants { // BlockID = 11

+112:0| 3: <1, 1> | i32:

+114:4| 3: <4, 2> | %c0 = i32 1;

+117:0| 0: <65534> | }

+ | | %b0:

+120:0| 3: <44, 0, 2, 0, 1> | call void %p0(i32 %c0);

+125:4| 3: <10> | ret void;

+127:2| 0: <65534> | }

+</pre>

+<h4 id="indirect-function-call">Indirect Function Call</h4>

+The indirect function call calls a function using a value that is an indirect

+function address. It is different from the direct function call because we can’t

+use the type signature of the corresponding literal function address to type

+check the construct.

+Syntax:

+<pre class="prettyprint">

+%vN = TAIL call RT V (T1 A1, ... , TM AM); <A>

+</pre>

+Record:

+<pre class="prettyprint">

+AA: <34, CC, RRT, VV, AA1, ... , AAM>

+</pre>

+Semantics:

+The indirect function call calls a function using a value <code>V</code> that is an

+indirect function address, and is assumed to return type <code>RT</code>. The arguments

+<code>A1</code> through <code>AM</code> are passed in the order specified. The type of argument

+<code>AI</code> must be type <code>TI</code> (for all I, 1 <= I <= N). Flag <code>TAIL</code> is

+optional. If it is included, it must be the literal <code>tail</code>.

+Each parameter type <code>TI</code> (1 <= I <= M), and return type <code>RT</code>, must either be

+a primitive type, or a vector type. If the parameter type is an integer type,

+it must either be i32 or i64.

+TAIL is encoded into calling convention value <code>CC</code> as follows:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">TAIL</th>

+<th class="head">CC</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>‘’</td>

+<td>0</td>

+</tr>

+<tr class="row-odd"><td>‘tail’</td>

+<td>1</td>

+</tr>

+</tbody>

+</table>

+The type signature of the called function is assumed to be:

+<pre class="prettyprint">

+RT (T1, ... , TN)

+</pre>

+It isn’t necessary to define this type in the <a class="reference internal" href="#link-for-types-block-section">types

+block</a>, since the type is inferred rather than

+used.

+Constraints:

+<pre class="prettyprint">

+AA == AbbrevIndex(A) &

+RRT = TypeID(RT) &

+VV = RelativeIndex(V) &

+M >= 0 &

+AbsoluteIndex(V) >= NumFcnAddresses &

+TypeOf(AI) == TI for all I, 1 <= I <= M &

+IsFcnArgType(TI) for all I, 1 <= I <= M &

+IsFcnArgType(RT) &

+N == NumValuedInsts

+</pre>

+Updates:

+<pre class="prettyprint">

+++NumValuedInsts;

+TypeOf(%vN) = RT;

+</pre>

+Examples:

+<pre class="prettyprint">

+ 40:0| 1: <65535, 17, 2> | types { // BlockID = 17

+ 48:0| 3: <1, 6> | count 6;

+ 50:4| 3: <7, 32> | @t0 = i32;

+ 53:6| 3: <3> | @t1 = float;

+ 55:4| 3: <4> | @t2 = double;

+ 57:2| 3: <21, 0, 0, 0, 1, 2> | @t3 = i32 (i32, float, double);

+ 62:6| 3: <21, 0, 0, 1, 2> | @t4 = i32 (float, double);

+ 67:4| 3: <2> | @t5 = void;

+ 69:2| 0: <65534> | }

+ ...

+104:0| 1: <65535, 12, 2> | function

+ | | i32

+ | | @f0(i32 %p0, float %p1,

+ | | double %p2) {

+ | | // BlockID = 12

+112:0| 3: <1, 1> | blocks 1;

+ | | %b0:

+114:4| 3: <44, 0, 3, 0, 2, 1> | %v0 = call i32

+ | | %p0(float %p1, double %p2);

+120:6| 3: <10, 1> | ret i32 %v0;

+123:2| 0: <65534> | }

+</pre>

+<h2 id="memory-blocks-and-alignment">Memory Blocks and Alignment</h2>

+In general, variable and heap allocated data are represented as byte addressable

+memory blocks. Alignment is always a power of 2, and defines an expectation on

+the memory address. That is, an alignment is met if the memory address is

+(evenly) divisible by the alignment. Note that alignment of 0 is never allowed.

+<blockquote>

+<div>Alignment plays a role at two points:</div></blockquote>

+<ul class="small-gap">

+<li>When you create a local/global variable</li>

+<li>When you load/store data using a pointer.</li>

+</ul>

+PNaClAsm allows most types to be placed at any address, and therefore can

+have alignment of 1. However, many architectures can load more efficiently

+if the data has an alignment that is larger than 1. As such, choosing a larger

+alignment can make load/stores more efficient.

+On loads and stores, the alignment in the instruction is used to communicate

+what assumptions the <a class="reference internal" href="/native-client/overview.html#link-for-pnacl-translator">PNaCl translator</a> can

+make when choosing the appropriate machine instructions. If the alignment is 1,

+it can’t assume anything about the memory address used by the instruction. When

+the alignment is greater than one, it can use that information to potentially

+chose a more efficient sequence of instructions to do the load/store.

+When laying out data within a variable, one also considers alignment. The reason

+for this is that if you want an address to be aligned, within the bytes defining

+the variable, you must choose an alignment for the variable that guarantees that

+alignment.

+In PNaClAsm, the valid load/store alignments are:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">Type</th>

+<th class="head">Alignment</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>i1</td>

+<td>1</td>

+</tr>

+<tr class="row-odd"><td>i8</td>

+<td>1</td>

+</tr>

+<tr class="row-even"><td>i16</td>

+<td>1</td>

+</tr>

+<tr class="row-odd"><td>i32</td>

+<td>1</td>

+</tr>

+<tr class="row-even"><td>i64</td>

+<td>1</td>

+</tr>

+<tr class="row-odd"><td>Float</td>

+<td>1, 4</td>

+</tr>

+<tr class="row-even"><td>Double</td>

+<td>1, 8</td>

+</tr>

+<tr class="row-odd"><td><4 x i1></td>

+<td>not applicable</td>

+</tr>

+<tr class="row-even"><td><8 x i1></td>

+<td>not applicable</td>

+</tr>

+<tr class="row-odd"><td><16 x i1></td>

+<td>not applicable</td>

+</tr>

+<tr class="row-even"><td><16 x i8></td>

+<td>1</td>

+</tr>

+<tr class="row-odd"><td><8 x i16></td>

+<td>2</td>

+</tr>

+<tr class="row-even"><td><4 x i32></td>

+<td>4</td>

+</tr>

+<tr class="row-odd"><td><4 x float></td>

+<td>4</td>

+</tr>

+</tbody>

+</table>

+Note that only vectors do not have an alignment value of 1. Hence, they can’t be

+placed at an arbitrary memory address. Also, since vectors on <code>i1</code> can’t be

+loaded/stored, the alignment is not applicable for these types.

+<h2 id="intrinsic-functions">Intrinsic Functions</h2>

+Intrinsic functions are special in PNaClAsm. They are implemented as specially

+named (external) function calls. The purpose of these intrinsic functions is to

+extend the PNaClAsm instruction set with additional functionality that is

+architecture specific. Hence, they either can’t be implemented within PNaClAsm,

+or a non-architecture specific implementation may be too slow on some

+architectures. In such cases, the <a class="reference internal" href="/native-client/overview.html#link-for-pnacl-translator">PNaCl

+translator</a> must fill in the corresponding

+implementation, since only it knows the architecture it is compiling down to.

+Examples of intrinsic function calls are for concurrent operations, atomic

+operations, bulk memory moves, thread pointer operations, and long jumps.

+It should be noted that calls to intrinsic functions do not have the same

+calling type constraints as ordinary functions. That is, an intrinsic can use

+any integer type for arguments/results, unlike ordinary functions (which

+restrict integer types to <code>i32</code> and <code>i64</code>).

+See the <a class="reference internal" href="/native-client/reference/pnacl-bitcode-abi.html">PNaCl bitcode reference manual</a> for the full

+set of intrinsic functions allowed. Note that in PNaClAsm, all pointer types to

+an (LLVM) intrinsic function is converted to type i32.

+<h2 id="support-functions">Support Functions</h2>

+Defines functions used to convert syntactic representation to values in the

+corresponding record.

+<h3 id="signrotate">SignRotate</h3>

+The SignRotate function encodes a signed integer in an easily compressible

+form. This is done by rotating the sign bit to the rightmost bit, rather than

+the leftmost bit. By doing this rotation, both small positive and negative

+integers are small (unsigned) integers. Therefore, all small integers can be

+encoded as a small (unsigned) integers.

+The definition of SignRotate(N) is:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">Argument</th>

+<th class="head">Value</th>

+<th class="head">Condition</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>N</td>

+<td>abs(N)<<1</td>

+<td>N >= 0</td>

+</tr>

+<tr class="row-odd"><td>N</td>

+<td>abs(N)<<1 + 1</td>

+<td>N < 0</td>

+</tr>

+</tbody>

+</table>

+<h3 id="absoluteindex">AbsoluteIndex</h3>

+Bitcode IDs of the forms <code>@fN</code>, <code>@gN</code>, <code>%pN</code>, <code>%cN</code>, and <code>%vN</code>, are

+combined into a single index space. This can be done because of the ordering

+imposed by PNaClAsm. All function address bitcode IDs must be defined before any

+of the other forms of bitcode IDs. All global address bitcode IDs must be

+defined before any local bitcode IDs. Within a function block, the parameter

+bitcode IDs must be defined before constant IDs, and constant IDs must be

+defined before instruction value IDs.

+Hence, within a function block, it is safe to refer to all of these

+bitcode IDs using a single absolute index. The absolute index for

+each kind of bitcode ID is computed as follows:

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">Bitcode ID</th>

+<th class="head">AbsoluteIndex</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>@tN</td>

+<td>N</td>

+</tr>

+<tr class="row-odd"><td>@fN</td>

+<td>N</td>

+</tr>

+<tr class="row-even"><td>@gN</td>

+<td>N + NumFcnAddresses</td>

+</tr>

+<tr class="row-odd"><td>@pN</td>

+<td>N + NumFcnAddresses + NumGlobalAddresses</td>

+</tr>

+<tr class="row-even"><td>@cN</td>

+<td>N + NumFcnAddresses + NumGlobalAddresses + NumParams</td>

+</tr>

+<tr class="row-odd"><td>@vN</td>

+<td>N + NumFcnAddresses + NumGlobalAddresses + NumParams + NumFcnConsts</td>

+</tr>

+</tbody>

+</table>

+<h3 id="relativeindex">RelativeIndex</h3>

+Relative indices are used to refer to values within instructions of a function.

+The relative index of an ID is always defined in terms of the index associated

+with the next value generating instruction. It is defined as follows:

+<pre class="prettyprint">

+RelativeIndex(J) = AbsoluteIndex(%vN) - AbsoluteIndex(J)

+</pre>

+where:

+<pre class="prettyprint">

+N = NumValuedInsts

+</pre>

+<h3 id="abbrevindex">AbbrevIndex</h3>

+This function converts user-defined abbreviation indices to the corresponding

+internal abbreviation index saved in the bitcode file. It adds 4 to its

+argument, since there are 4 predefined internal abbreviation indices (0, 1, 2,

+and 3).

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">N</th>

+<th class="head">AbbrevIndex(N)</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>undefined</td>

+<td>3</td>

+</tr>

+<tr class="row-odd"><td>%aA</td>

+<td>A + 4</td>

+</tr>

+<tr class="row-even"><td>@aA</td>

+<td>A + 4</td>

+</tr>

+</tbody>

+</table>

+<h3 id="log2">Log2</h3>

+This is the 32-bit log2 value of its argument.

+<h3 id="bitsizeof">BitSizeOf</h3>

+Returns the number of bits needed to represent its argument (a type).

+<table border="1" class="docutils">

+<colgroup>

+</colgroup>

+<thead valign="bottom">

+<tr class="row-odd"><th class="head">T</th>

+<th class="head">BitSizeOf</th>

+</tr>

+</thead>

+<tbody valign="top">

+<tr class="row-even"><td>i1</td>

+<td>1</td>

+</tr>

+<tr class="row-odd"><td>i8</td>

+<td>8</td>

+</tr>

+<tr class="row-even"><td>i16</td>

+<td>16</td>

+</tr>

+<tr class="row-odd"><td>i32</td>

+<td>32</td>

+</tr>

+<tr class="row-even"><td>i64</td>

+<td>64</td>

+</tr>

+<tr class="row-odd"><td>float</td>

+<td>32</td>

+</tr>

+<tr class="row-even"><td>double</td>

+<td>64</td>

+</tr>

+<tr class="row-odd"><td><N X T></td>

+<td>N * BitSizeOf(T)</td>

+</tr>

+</tbody>

+</table>

+<h3 id="underlyingtype">UnderlyingType</h3>

+Returns the primitive type of the type construct. For primitive types, the

+UnderlyingType is itself. For vector types, the base type of the vector is the

+underlying type.

+<h3 id="underlyingcount">UnderlyingCount</h3>

+Returns the size of the vector if given a vector, and 0 for primitive types.

+Note that this function is used to check if two vectors are of the same size.

+It is also used to test if two types are either primitive (i.e. UnderlyingCount

+returns 0 for both types) or are vectors of the same size (i.e. UnderlyingCount

+returns the same non-zero value).

+<h3 id="isinteger">IsInteger</h3>

+Returns true if the argument is in {i1, i8, i16, i32, i64}.

+<h3 id="isfloat">IsFloat</h3>

+Returns true if the argument is in {<code>float</code>, <code>double</code>}.

+<h3 id="isvector">IsVector</h3>

+Returns true if the argument is a vector type.

+<h3 id="isprimitive">IsPrimitive</h3>

+Returns true if the argument is a primitive type. That is:

+<pre class="prettyprint">

+IsPrimitive(T) == IsInteger(T) or IsFloat(T)

+</pre>

+<h3 id="isfcnargtype">IsFcnArgType</h3>

+Returns true if the argument is a primitive type or a vector type. Further,

+if it is an integer type, it must be i32 or i64. That is:

+<pre class="prettyprint">

+IsFcnArgType(T) = (IsInteger(T) and (i32 = BitSizeOf(T)

+ or i64 == BitSizeOf(T)))

+ or IsFloat(T) or IsVector(T)

+</pre>

+<h2 id="abbreviations">Abbreviations</h2>

+Abbreviations are used to convert PNaCl records to a sequence of bits. PNaCl

+uses the same strategy as <a class="reference external" href="http://llvm.org/docs/BitCodeFormat.html">LLVM’s bitcode file format</a>. See that document for more

+details.

+It should be noted that we replace LLVM’s header (called the Bitcode Wrapper

+Format) with the bytes of the <a class="reference internal" href="#link-for-header-record-section">PNaCl record

+header</a>. In addition, PNaCl bitcode files do

+not allow blob abbreviation.

+<h3 id="abbreviations-block">Abbreviations Block</h3>

+The abbreviations block is the first block in the module build. The

+block is divided into sections. Each section is a sequence of records. Each

+record in the sequence defines a user-defined abbreviation. Each section

+defines abbreviations that can be applied to all (succeeding) blocks of a

+particular kind. These abbreviations are denoted by the (global) ID of the form

+@aN.

+In terms of <a class="reference external" href="http://llvm.org/docs/BitCodeFormat.html">LLVM’s bitcode file format</a>, the abbreviations block is called a

+BLOCKINFO block. Records SETBID and DEFINE_ABBREV are the only records

+allowed in PNaCl’s abbreviation block (i.e. it doesn’t allow BLOCKNAME and

+SETRECORDNAME records).

+<h3 id="todo">TODO</h3>

+Extend this document to describe PNaCl’s bitcode bit sequencer

+without requiring the reader to refer to <a class="reference external" href="http://llvm.org/docs/BitCodeFormat.html">LLVM’s bitcode file

+format</a>.

+</section>

+{{/partials.standard_nacl_article}}