Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / llvm / ce718ff9f42c7da092eaa01dd0242e8d5ba84713 / . / docs / BitCodeFormat.html
blob: 6a670f56b978ad1ecec65e7b43f07aadebc574fe [file] [log] [blame]
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
2 "http://www.w3.org/TR/html4/strict.dtd">
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]3<html>
4<head>
5 <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
6 <title>LLVM Bitcode File Format</title>
Daniel Dunbaradea4972012-04-19 20:20:34 +0000[diff] [blame]7 <link rel="stylesheet" href="_static/llvm.css" type="text/css">
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]8</head>
9<body>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]10<h1> LLVM Bitcode File Format</h1>
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]11<ol>
12 <li><a href="#abstract">Abstract</a></li>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]13 <li><a href="#overview">Overview</a></li>
14 <li><a href="#bitstream">Bitstream Format</a>
15 <ol>
16 <li><a href="#magic">Magic Numbers</a></li>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]17 <li><a href="#primitives">Primitives</a></li>
18 <li><a href="#abbrevid">Abbreviation IDs</a></li>
19 <li><a href="#blocks">Blocks</a></li>
20 <li><a href="#datarecord">Data Records</a></li>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]21 <li><a href="#abbreviations">Abbreviations</a></li>
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]22 <li><a href="#stdblocks">Standard Blocks</a></li>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]23 </ol>
24 </li>
Chris Lattner6fa6a322008-07-09 05:14:23 +0000[diff] [blame]25 <li><a href="#wrapper">Bitcode Wrapper Format</a>
26 </li>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]27 <li><a href="#llvmir">LLVM IR Encoding</a>
28 <ol>
29 <li><a href="#basics">Basics</a></li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]30 <li><a href="#MODULE_BLOCK">MODULE_BLOCK Contents</a></li>
31 <li><a href="#PARAMATTR_BLOCK">PARAMATTR_BLOCK Contents</a></li>
32 <li><a href="#TYPE_BLOCK">TYPE_BLOCK Contents</a></li>
33 <li><a href="#CONSTANTS_BLOCK">CONSTANTS_BLOCK Contents</a></li>
34 <li><a href="#FUNCTION_BLOCK">FUNCTION_BLOCK Contents</a></li>
35 <li><a href="#TYPE_SYMTAB_BLOCK">TYPE_SYMTAB_BLOCK Contents</a></li>
36 <li><a href="#VALUE_SYMTAB_BLOCK">VALUE_SYMTAB_BLOCK Contents</a></li>
37 <li><a href="#METADATA_BLOCK">METADATA_BLOCK Contents</a></li>
38 <li><a href="#METADATA_ATTACHMENT">METADATA_ATTACHMENT Contents</a></li>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]39 </ol>
40 </li>
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]41</ol>
42<div class="doc_author">
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]43 <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a>,
44 <a href="http://www.reverberate.org">Joshua Haberman</a>,
45 and <a href="mailto:housel@acm.org">Peter S. Housel</a>.
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]46</p>
47</div>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]48
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]49<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]50<h2><a name="abstract">Abstract</a></h2>
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]51<!-- *********************************************************************** -->
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]52
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]53<div>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]54
55<p>This document describes the LLVM bitstream file format and the encoding of
56the LLVM IR into it.</p>
57
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]58</div>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]59
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]60<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]61<h2><a name="overview">Overview</a></h2>
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]62<!-- *********************************************************************** -->
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]63
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]64<div>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]65
66<p>
67What is commonly known as the LLVM bitcode file format (also, sometimes
68anachronistically known as bytecode) is actually two things: a <a
69href="#bitstream">bitstream container format</a>
70and an <a href="#llvmir">encoding of LLVM IR</a> into the container format.</p>
71
72<p>
Reid Spencer58d05472007-05-12 08:01:52 +0000[diff] [blame]73The bitstream format is an abstract encoding of structured data, very
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]74similar to XML in some ways. Like XML, bitstream files contain tags, and nested
75structures, and you can parse the file without having to understand the tags.
76Unlike XML, the bitstream format is a binary encoding, and unlike XML it
77provides a mechanism for the file to self-describe "abbreviations", which are
78effectively size optimizations for the content.</p>
79
Chris Lattner6fa6a322008-07-09 05:14:23 +0000[diff] [blame]80<p>LLVM IR files may be optionally embedded into a <a
81href="#wrapper">wrapper</a> structure that makes it easy to embed extra data
82along with LLVM IR files.</p>
83
84<p>This document first describes the LLVM bitstream format, describes the
85wrapper format, then describes the record structure used by LLVM IR files.
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]86</p>
87
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]88</div>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]89
90<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]91<h2><a name="bitstream">Bitstream Format</a></h2>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]92<!-- *********************************************************************** -->
93
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]94<div>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]95
96<p>
97The bitstream format is literally a stream of bits, with a very simple
98structure. This structure consists of the following concepts:
99</p>
100
101<ul>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]102<li>A "<a href="#magic">magic number</a>" that identifies the contents of
103 the stream.</li>
104<li>Encoding <a href="#primitives">primitives</a> like variable bit-rate
105 integers.</li>
106<li><a href="#blocks">Blocks</a>, which define nested content.</li>
107<li><a href="#datarecord">Data Records</a>, which describe entities within the
108 file.</li>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]109<li>Abbreviations, which specify compression optimizations for the file.</li>
110</ul>
111
112<p>Note that the <a
113href="CommandGuide/html/llvm-bcanalyzer.html">llvm-bcanalyzer</a> tool can be
114used to dump and inspect arbitrary bitstreams, which is very useful for
115understanding the encoding.</p>
116
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]117<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]118<h3>
119 <a name="magic">Magic Numbers</a>
120</h3>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]121
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]122<div>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]123
Chris Lattnerf19b8e42007-10-08 18:42:45 +0000[diff] [blame]124<p>The first two bytes of a bitcode file are 'BC' (0x42, 0x43).
125The second two bytes are an application-specific magic number. Generic
126bitcode tools can look at only the first two bytes to verify the file is
127bitcode, while application-specific programs will want to look at all four.</p>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]128
129</div>
130
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]131<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]132<h3>
133 <a name="primitives">Primitives</a>
134</h3>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]135
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]136<div>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]137
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]138<p>
Chris Lattnerf19b8e42007-10-08 18:42:45 +0000[diff] [blame]139A bitstream literally consists of a stream of bits, which are read in order
140starting with the least significant bit of each byte. The stream is made up of a
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]141number of primitive values that encode a stream of unsigned integer values.
Chris Lattnerf958dd22010-01-20 17:53:51 +0000[diff] [blame]142These integers are encoded in two ways: either as <a href="#fixedwidth">Fixed
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]143Width Integers</a> or as <a href="#variablewidth">Variable Width
144Integers</a>.
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]145</p>
146
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]147<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]148<h4>
149 <a name="fixedwidth">Fixed Width Integers</a>
150</h4>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]151
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]152<div>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]153
154<p>Fixed-width integer values have their low bits emitted directly to the file.
155 For example, a 3-bit integer value encodes 1 as 001. Fixed width integers
156 are used when there are a well-known number of options for a field. For
157 example, boolean values are usually encoded with a 1-bit wide integer.
158</p>
159
160</div>
161
162<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]163<h4>
164 <a name="variablewidth">Variable Width Integers</a>
165</h4>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]166
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]167<div>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]168
169<p>Variable-width integer (VBR) values encode values of arbitrary size,
170optimizing for the case where the values are small. Given a 4-bit VBR field,
171any 3-bit value (0 through 7) is encoded directly, with the high bit set to
172zero. Values larger than N-1 bits emit their bits in a series of N-1 bit
173chunks, where all but the last set the high bit.</p>
174
175<p>For example, the value 27 (0x1B) is encoded as 1011 0011 when emitted as a
176vbr4 value. The first set of four bits indicates the value 3 (011) with a
177continuation piece (indicated by a high bit of 1). The next word indicates a
178value of 24 (011 << 3) with no continuation. The sum (3+24) yields the value
17927.
180</p>
181
182</div>
183
184<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]185<h4><a name="char6">6-bit characters</a></h4>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]186
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]187<div>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]188
189<p>6-bit characters encode common characters into a fixed 6-bit field. They
Chris Lattnerf1d64e92007-05-12 07:50:14 +0000[diff] [blame]190represent the following characters with the following 6-bit values:</p>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]191
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]192<div class="doc_code">
193<pre>
194'a' .. 'z' &mdash; 0 .. 25
195'A' .. 'Z' &mdash; 26 .. 51
196'0' .. '9' &mdash; 52 .. 61
197 '.' &mdash; 62
198 '_' &mdash; 63
199</pre>
200</div>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]201
202<p>This encoding is only suitable for encoding characters and strings that
203consist only of the above characters. It is completely incapable of encoding
204characters not in the set.</p>
205
206</div>
207
208<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]209<h4><a name="wordalign">Word Alignment</a></h4>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]210
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]211<div>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]212
213<p>Occasionally, it is useful to emit zero bits until the bitstream is a
214multiple of 32 bits. This ensures that the bit position in the stream can be
215represented as a multiple of 32-bit words.</p>
216
217</div>
218
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]219</div>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]220
221<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]222<h3>
223 <a name="abbrevid">Abbreviation IDs</a>
224</h3>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]225
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]226<div>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]227
228<p>
229A bitstream is a sequential series of <a href="#blocks">Blocks</a> and
230<a href="#datarecord">Data Records</a>. Both of these start with an
231abbreviation ID encoded as a fixed-bitwidth field. The width is specified by
232the current block, as described below. The value of the abbreviation ID
233specifies either a builtin ID (which have special meanings, defined below) or
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]234one of the abbreviation IDs defined for the current block by the stream itself.
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]235</p>
236
237<p>
238The set of builtin abbrev IDs is:
239</p>
240
241<ul>
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]242<li><tt>0 - <a href="#END_BLOCK">END_BLOCK</a></tt> &mdash; This abbrev ID marks
243 the end of the current block.</li>
244<li><tt>1 - <a href="#ENTER_SUBBLOCK">ENTER_SUBBLOCK</a></tt> &mdash; This
245 abbrev ID marks the beginning of a new block.</li>
246<li><tt>2 - <a href="#DEFINE_ABBREV">DEFINE_ABBREV</a></tt> &mdash; This defines
247 a new abbreviation.</li>
248<li><tt>3 - <a href="#UNABBREV_RECORD">UNABBREV_RECORD</a></tt> &mdash; This ID
249 specifies the definition of an unabbreviated record.</li>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]250</ul>
251
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]252<p>Abbreviation IDs 4 and above are defined by the stream itself, and specify
253an <a href="#abbrev_records">abbreviated record encoding</a>.</p>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]254
255</div>
256
257<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]258<h3>
259 <a name="blocks">Blocks</a>
260</h3>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]261
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]262<div>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]263
264<p>
265Blocks in a bitstream denote nested regions of the stream, and are identified by
266a content-specific id number (for example, LLVM IR uses an ID of 12 to represent
Chris Lattnerf19b8e42007-10-08 18:42:45 +0000[diff] [blame]267function bodies). Block IDs 0-7 are reserved for <a href="#stdblocks">standard blocks</a>
268whose meaning is defined by Bitcode; block IDs 8 and greater are
Benjamin Kramer8040cd32009-10-12 14:46:08 +0000[diff] [blame]269application specific. Nested blocks capture the hierarchical structure of the data
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]270encoded in it, and various properties are associated with blocks as the file is
271parsed. Block definitions allow the reader to efficiently skip blocks
272in constant time if the reader wants a summary of blocks, or if it wants to
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]273efficiently skip data it does not understand. The LLVM IR reader uses this
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]274mechanism to skip function bodies, lazily reading them on demand.
275</p>
276
277<p>
278When reading and encoding the stream, several properties are maintained for the
279block. In particular, each block maintains:
280</p>
281
282<ol>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]283<li>A current abbrev id width. This value starts at 2 at the beginning of
284 the stream, and is set every time a
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]285 block record is entered. The block entry specifies the abbrev id width for
286 the body of the block.</li>
287
Chris Lattnerf19b8e42007-10-08 18:42:45 +0000[diff] [blame]288<li>A set of abbreviations. Abbreviations may be defined within a block, in
289 which case they are only defined in that block (neither subblocks nor
290 enclosing blocks see the abbreviation). Abbreviations can also be defined
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]291 inside a <tt><a href="#BLOCKINFO">BLOCKINFO</a></tt> block, in which case
292 they are defined in all blocks that match the ID that the BLOCKINFO block is
293 describing.
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]294</li>
295</ol>
296
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]297<p>
298As sub blocks are entered, these properties are saved and the new sub-block has
299its own set of abbreviations, and its own abbrev id width. When a sub-block is
300popped, the saved values are restored.
301</p>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]302
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]303<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]304<h4><a name="ENTER_SUBBLOCK">ENTER_SUBBLOCK Encoding</a></h4>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]305
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]306<div>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]307
308<p><tt>[ENTER_SUBBLOCK, blockid<sub>vbr8</sub>, newabbrevlen<sub>vbr4</sub>,
309 &lt;align32bits&gt;, blocklen<sub>32</sub>]</tt></p>
310
311<p>
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]312The <tt>ENTER_SUBBLOCK</tt> abbreviation ID specifies the start of a new block
313record. The <tt>blockid</tt> value is encoded as an 8-bit VBR identifier, and
314indicates the type of block being entered, which can be
315a <a href="#stdblocks">standard block</a> or an application-specific block.
316The <tt>newabbrevlen</tt> value is a 4-bit VBR, which specifies the abbrev id
317width for the sub-block. The <tt>blocklen</tt> value is a 32-bit aligned value
318that specifies the size of the subblock in 32-bit words. This value allows the
319reader to skip over the entire block in one jump.
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]320</p>
321
322</div>
323
324<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]325<h4><a name="END_BLOCK">END_BLOCK Encoding</a></h4>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]326
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]327<div>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]328
329<p><tt>[END_BLOCK, &lt;align32bits&gt;]</tt></p>
330
331<p>
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]332The <tt>END_BLOCK</tt> abbreviation ID specifies the end of the current block
333record. Its end is aligned to 32-bits to ensure that the size of the block is
334an even multiple of 32-bits.
335</p>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]336
337</div>
338
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]339</div>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]340
341<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]342<h3>
343 <a name="datarecord">Data Records</a>
344</h3>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]345
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]346<div>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]347<p>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]348Data records consist of a record code and a number of (up to) 64-bit
349integer values. The interpretation of the code and values is
350application specific and may vary between different block types.
351Records can be encoded either using an unabbrev record, or with an
352abbreviation. In the LLVM IR format, for example, there is a record
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]353which encodes the target triple of a module. The code is
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]354<tt>MODULE_CODE_TRIPLE</tt>, and the values of the record are the
355ASCII codes for the characters in the string.
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]356</p>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]357
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]358<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]359<h4><a name="UNABBREV_RECORD">UNABBREV_RECORD Encoding</a></h4>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]360
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]361<div>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]362
363<p><tt>[UNABBREV_RECORD, code<sub>vbr6</sub>, numops<sub>vbr6</sub>,
364 op0<sub>vbr6</sub>, op1<sub>vbr6</sub>, ...]</tt></p>
365
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]366<p>
367An <tt>UNABBREV_RECORD</tt> provides a default fallback encoding, which is both
368completely general and extremely inefficient. It can describe an arbitrary
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]369record by emitting the code and operands as VBRs.
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]370</p>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]371
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]372<p>
373For example, emitting an LLVM IR target triple as an unabbreviated record
374requires emitting the <tt>UNABBREV_RECORD</tt> abbrevid, a vbr6 for the
375<tt>MODULE_CODE_TRIPLE</tt> code, a vbr6 for the length of the string, which is
376equal to the number of operands, and a vbr6 for each character. Because there
377are no letters with values less than 32, each letter would need to be emitted as
378at least a two-part VBR, which means that each letter would require at least 12
379bits. This is not an efficient encoding, but it is fully general.
380</p>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]381
382</div>
383
384<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]385<h4><a name="abbrev_records">Abbreviated Record Encoding</a></h4>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]386
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]387<div>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]388
389<p><tt>[&lt;abbrevid&gt;, fields...]</tt></p>
390
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]391<p>
392An abbreviated record is a abbreviation id followed by a set of fields that are
393encoded according to the <a href="#abbreviations">abbreviation definition</a>.
394This allows records to be encoded significantly more densely than records
395encoded with the <tt><a href="#UNABBREV_RECORD">UNABBREV_RECORD</a></tt> type,
396and allows the abbreviation types to be specified in the stream itself, which
397allows the files to be completely self describing. The actual encoding of
398abbreviations is defined below.
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]399</p>
400
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]401<p>The record code, which is the first field of an abbreviated record,
402may be encoded in the abbreviation definition (as a literal
403operand) or supplied in the abbreviated record (as a Fixed or VBR
404operand value).</p>
405
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]406</div>
407
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]408</div>
409
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]410<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]411<h3>
412 <a name="abbreviations">Abbreviations</a>
413</h3>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]414
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]415<div>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]416<p>
417Abbreviations are an important form of compression for bitstreams. The idea is
418to specify a dense encoding for a class of records once, then use that encoding
419to emit many records. It takes space to emit the encoding into the file, but
420the space is recouped (hopefully plus some) when the records that use it are
421emitted.
422</p>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]423
424<p>
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]425Abbreviations can be determined dynamically per client, per file. Because the
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]426abbreviations are stored in the bitstream itself, different streams of the same
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]427format can contain different sets of abbreviations according to the needs
428of the specific stream.
429As a concrete example, LLVM IR files usually emit an abbreviation
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]430for binary operators. If a specific LLVM module contained no or few binary
431operators, the abbreviation does not need to be emitted.
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]432</p>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]433
434<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]435<h4><a name="DEFINE_ABBREV">DEFINE_ABBREV Encoding</a></h4>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]436
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]437<div>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]438
439<p><tt>[DEFINE_ABBREV, numabbrevops<sub>vbr5</sub>, abbrevop0, abbrevop1,
440 ...]</tt></p>
441
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]442<p>
443A <tt>DEFINE_ABBREV</tt> record adds an abbreviation to the list of currently
444defined abbreviations in the scope of this block. This definition only exists
445inside this immediate block &mdash; it is not visible in subblocks or enclosing
446blocks. Abbreviations are implicitly assigned IDs sequentially starting from 4
447(the first application-defined abbreviation ID). Any abbreviations defined in a
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]448<tt>BLOCKINFO</tt> record for the particular block type
449receive IDs first, in order, followed by any
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]450abbreviations defined within the block itself. Abbreviated data records
451reference this ID to indicate what abbreviation they are invoking.
452</p>
Chris Lattnerf19b8e42007-10-08 18:42:45 +0000[diff] [blame]453
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]454<p>
455An abbreviation definition consists of the <tt>DEFINE_ABBREV</tt> abbrevid
456followed by a VBR that specifies the number of abbrev operands, then the abbrev
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]457operands themselves. Abbreviation operands come in three forms. They all start
458with a single bit that indicates whether the abbrev operand is a literal operand
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]459(when the bit is 1) or an encoding operand (when the bit is 0).
460</p>
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]461
462<ol>
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]463<li>Literal operands &mdash; <tt>[1<sub>1</sub>, litvalue<sub>vbr8</sub>]</tt>
464&mdash; Literal operands specify that the value in the result is always a single
465specific value. This specific value is emitted as a vbr8 after the bit
466indicating that it is a literal operand.</li>
467<li>Encoding info without data &mdash; <tt>[0<sub>1</sub>,
468 encoding<sub>3</sub>]</tt> &mdash; Operand encodings that do not have extra
469 data are just emitted as their code.
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]470</li>
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]471<li>Encoding info with data &mdash; <tt>[0<sub>1</sub>, encoding<sub>3</sub>,
472value<sub>vbr5</sub>]</tt> &mdash; Operand encodings that do have extra data are
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]473emitted as their code, followed by the extra data.
Chris Lattnerdaeb63c2007-05-12 07:49:15 +0000[diff] [blame]474</li>
475</ol>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]476
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]477<p>The possible operand encodings are:</p>
478
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]479<ul>
480<li>Fixed (code 1): The field should be emitted as
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]481 a <a href="#fixedwidth">fixed-width value</a>, whose width is specified by
482 the operand's extra data.</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]483<li>VBR (code 2): The field should be emitted as
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]484 a <a href="#variablewidth">variable-width value</a>, whose width is
485 specified by the operand's extra data.</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]486<li>Array (code 3): This field is an array of values. The array operand
487 has no extra data, but expects another operand to follow it, indicating
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]488 the element type of the array. When reading an array in an abbreviated
489 record, the first integer is a vbr6 that indicates the array length,
490 followed by the encoded elements of the array. An array may only occur as
491 the last operand of an abbreviation (except for the one final operand that
492 gives the array's type).</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]493<li>Char6 (code 4): This field should be emitted as
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]494 a <a href="#char6">char6-encoded value</a>. This operand type takes no
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]495 extra data. Char6 encoding is normally used as an array element type.
496 </li>
497<li>Blob (code 5): This field is emitted as a vbr6, followed by padding to a
Chris Lattnerdcd006b2009-04-06 21:50:39 +0000[diff] [blame]498 32-bit boundary (for alignment) and an array of 8-bit objects. The array of
499 bytes is further followed by tail padding to ensure that its total length is
500 a multiple of 4 bytes. This makes it very efficient for the reader to
501 decode the data without having to make a copy of it: it can use a pointer to
502 the data in the mapped in file and poke directly at it. A blob may only
503 occur as the last operand of an abbreviation.</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]504</ul>
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]505
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]506<p>
507For example, target triples in LLVM modules are encoded as a record of the
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]508form <tt>[TRIPLE, 'a', 'b', 'c', 'd']</tt>. Consider if the bitstream emitted
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]509the following abbrev entry:
510</p>
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]511
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]512<div class="doc_code">
513<pre>
514[0, Fixed, 4]
515[0, Array]
516[0, Char6]
517</pre>
518</div>
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]519
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]520<p>
521When emitting a record with this abbreviation, the above entry would be emitted
522as:
523</p>
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]524
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]525<div class="doc_code">
Bill Wendling903bcc42009-04-04 22:36:02 +0000[diff] [blame]526<p>
527<tt>[4<sub>abbrevwidth</sub>, 2<sub>4</sub>, 4<sub>vbr6</sub>, 0<sub>6</sub>,
5281<sub>6</sub>, 2<sub>6</sub>, 3<sub>6</sub>]</tt>
529</p>
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]530</div>
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]531
532<p>These values are:</p>
533
534<ol>
535<li>The first value, 4, is the abbreviation ID for this abbreviation.</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]536<li>The second value, 2, is the record code for <tt>TRIPLE</tt> records within LLVM IR file <tt>MODULE_BLOCK</tt> blocks.</li>
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]537<li>The third value, 4, is the length of the array.</li>
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]538<li>The rest of the values are the char6 encoded values
539 for <tt>"abcd"</tt>.</li>
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]540</ol>
541
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]542<p>
543With this abbreviation, the triple is emitted with only 37 bits (assuming a
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]544abbrev id width of 3). Without the abbreviation, significantly more space would
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]545be required to emit the target triple. Also, because the <tt>TRIPLE</tt> value
546is not emitted as a literal in the abbreviation, the abbreviation can also be
547used for any other string value.
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]548</p>
549
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]550</div>
551
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]552</div>
553
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]554<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]555<h3>
556 <a name="stdblocks">Standard Blocks</a>
557</h3>
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]558
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]559<div>
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]560
561<p>
562In addition to the basic block structure and record encodings, the bitstream
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]563also defines specific built-in block types. These block types specify how the
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]564stream is to be decoded or other metadata. In the future, new standard blocks
Chris Lattnerf19b8e42007-10-08 18:42:45 +0000[diff] [blame]565may be added. Block IDs 0-7 are reserved for standard blocks.
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]566</p>
567
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]568<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]569<h4><a name="BLOCKINFO">#0 - BLOCKINFO Block</a></h4>
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]570
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]571<div>
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]572
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]573<p>
574The <tt>BLOCKINFO</tt> block allows the description of metadata for other
575blocks. The currently specified records are:
576</p>
577
578<div class="doc_code">
579<pre>
580[SETBID (#1), blockid]
581[DEFINE_ABBREV, ...]
Chris Lattnerf9a3ec82009-04-26 22:21:57 +0000[diff] [blame]582[BLOCKNAME, ...name...]
583[SETRECORDNAME, RecordID, ...name...]
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]584</pre>
585</div>
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]586
587<p>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]588The <tt>SETBID</tt> record (code 1) indicates which block ID is being
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]589described. <tt>SETBID</tt> records can occur multiple times throughout the
590block to change which block ID is being described. There must be
591a <tt>SETBID</tt> record prior to any other records.
Chris Lattnerf19b8e42007-10-08 18:42:45 +0000[diff] [blame]592</p>
593
594<p>
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]595Standard <tt>DEFINE_ABBREV</tt> records can occur inside <tt>BLOCKINFO</tt>
596blocks, but unlike their occurrence in normal blocks, the abbreviation is
597defined for blocks matching the block ID we are describing, <i>not</i> the
598<tt>BLOCKINFO</tt> block itself. The abbreviations defined
599in <tt>BLOCKINFO</tt> blocks receive abbreviation IDs as described
600in <tt><a href="#DEFINE_ABBREV">DEFINE_ABBREV</a></tt>.
Chris Lattnerf19b8e42007-10-08 18:42:45 +0000[diff] [blame]601</p>
602
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]603<p>The <tt>BLOCKNAME</tt> record (code 2) can optionally occur in this block. The elements of
604the record are the bytes of the string name of the block. llvm-bcanalyzer can use
Chris Lattnerf9a3ec82009-04-26 22:21:57 +0000[diff] [blame]605this to dump out bitcode files symbolically.</p>
606
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]607<p>The <tt>SETRECORDNAME</tt> record (code 3) can also optionally occur in this block. The
608first operand value is a record ID number, and the rest of the elements of the record are
609the bytes for the string name of the record. llvm-bcanalyzer can use
Chris Lattnerf9a3ec82009-04-26 22:21:57 +0000[diff] [blame]610this to dump out bitcode files symbolically.</p>
611
Chris Lattnerf19b8e42007-10-08 18:42:45 +0000[diff] [blame]612<p>
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]613Note that although the data in <tt>BLOCKINFO</tt> blocks is described as
614"metadata," the abbreviations they contain are essential for parsing records
615from the corresponding blocks. It is not safe to skip them.
Chris Lattner7300af52007-05-13 00:59:52 +0000[diff] [blame]616</p>
617
618</div>
Chris Lattner3a1716d2007-05-12 05:37:42 +0000[diff] [blame]619
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]620</div>
621
622</div>
623
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]624<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]625<h2><a name="wrapper">Bitcode Wrapper Format</a></h2>
Chris Lattner6fa6a322008-07-09 05:14:23 +0000[diff] [blame]626<!-- *********************************************************************** -->
627
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]628<div>
Chris Lattner6fa6a322008-07-09 05:14:23 +0000[diff] [blame]629
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]630<p>
631Bitcode files for LLVM IR may optionally be wrapped in a simple wrapper
Chris Lattner6fa6a322008-07-09 05:14:23 +0000[diff] [blame]632structure. This structure contains a simple header that indicates the offset
633and size of the embedded BC file. This allows additional information to be
634stored alongside the BC file. The structure of this file header is:
635</p>
636
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]637<div class="doc_code">
Bill Wendling903bcc42009-04-04 22:36:02 +0000[diff] [blame]638<p>
639<tt>[Magic<sub>32</sub>, Version<sub>32</sub>, Offset<sub>32</sub>,
640Size<sub>32</sub>, CPUType<sub>32</sub>]</tt>
641</p>
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]642</div>
Chris Lattner6fa6a322008-07-09 05:14:23 +0000[diff] [blame]643
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]644<p>
645Each of the fields are 32-bit fields stored in little endian form (as with
Chris Lattner6fa6a322008-07-09 05:14:23 +0000[diff] [blame]646the rest of the bitcode file fields). The Magic number is always
647<tt>0x0B17C0DE</tt> and the version is currently always <tt>0</tt>. The Offset
648field is the offset in bytes to the start of the bitcode stream in the file, and
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]649the Size field is the size in bytes of the stream. CPUType is a target-specific
Chris Lattner6fa6a322008-07-09 05:14:23 +0000[diff] [blame]650value that can be used to encode the CPU of the target.
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]651</p>
Chris Lattner6fa6a322008-07-09 05:14:23 +0000[diff] [blame]652
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]653</div>
Chris Lattner6fa6a322008-07-09 05:14:23 +0000[diff] [blame]654
655<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]656<h2><a name="llvmir">LLVM IR Encoding</a></h2>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]657<!-- *********************************************************************** -->
658
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]659<div>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]660
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]661<p>
662LLVM IR is encoded into a bitstream by defining blocks and records. It uses
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]663blocks for things like constant pools, functions, symbol tables, etc. It uses
664records for things like instructions, global variable descriptors, type
665descriptions, etc. This document does not describe the set of abbreviations
666that the writer uses, as these are fully self-described in the file, and the
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]667reader is not allowed to build in any knowledge of this.
668</p>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]669
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]670<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]671<h3>
672 <a name="basics">Basics</a>
673</h3>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]674
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]675<div>
676
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]677<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]678<h4><a name="ir_magic">LLVM IR Magic Number</a></h4>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]679
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]680<div>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]681
682<p>
683The magic number for LLVM IR files is:
684</p>
685
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]686<div class="doc_code">
Bill Wendling903bcc42009-04-04 22:36:02 +0000[diff] [blame]687<p>
688<tt>[0x0<sub>4</sub>, 0xC<sub>4</sub>, 0xE<sub>4</sub>, 0xD<sub>4</sub>]</tt>
689</p>
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]690</div>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]691
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]692<p>
693When combined with the bitcode magic number and viewed as bytes, this is
694<tt>"BC&nbsp;0xC0DE"</tt>.
695</p>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]696
697</div>
698
699<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]700<h4><a name="ir_signed_vbr">Signed VBRs</a></h4>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]701
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]702<div>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]703
704<p>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]705<a href="#variablewidth">Variable Width Integer</a> encoding is an efficient way to
706encode arbitrary sized unsigned values, but is an extremely inefficient for
707encoding signed values, as signed values are otherwise treated as maximally large
708unsigned values.
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]709</p>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]710
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]711<p>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]712As such, signed VBR values of a specific width are emitted as follows:
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]713</p>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]714
715<ul>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]716<li>Positive values are emitted as VBRs of the specified width, but with their
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]717 value shifted left by one.</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]718<li>Negative values are emitted as VBRs of the specified width, but the negated
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]719 value is shifted left by one, and the low bit is set.</li>
720</ul>
721
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]722<p>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]723With this encoding, small positive and small negative values can both
724be emitted efficiently. Signed VBR encoding is used in
725<tt>CST_CODE_INTEGER</tt> and <tt>CST_CODE_WIDE_INTEGER</tt> records
726within <tt>CONSTANTS_BLOCK</tt> blocks.
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]727</p>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]728
729</div>
730
731
732<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]733<h4><a name="ir_blocks">LLVM IR Blocks</a></h4>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]734
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]735<div>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]736
737<p>
738LLVM IR is defined with the following blocks:
739</p>
740
741<ul>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]742<li>8 &mdash; <a href="#MODULE_BLOCK"><tt>MODULE_BLOCK</tt></a> &mdash; This is the top-level block that
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]743 contains the entire module, and describes a variety of per-module
744 information.</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]745<li>9 &mdash; <a href="#PARAMATTR_BLOCK"><tt>PARAMATTR_BLOCK</tt></a> &mdash; This enumerates the parameter
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]746 attributes.</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]747<li>10 &mdash; <a href="#TYPE_BLOCK"><tt>TYPE_BLOCK</tt></a> &mdash; This describes all of the types in
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]748 the module.</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]749<li>11 &mdash; <a href="#CONSTANTS_BLOCK"><tt>CONSTANTS_BLOCK</tt></a> &mdash; This describes constants for a
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]750 module or function.</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]751<li>12 &mdash; <a href="#FUNCTION_BLOCK"><tt>FUNCTION_BLOCK</tt></a> &mdash; This describes a function
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]752 body.</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]753<li>13 &mdash; <a href="#TYPE_SYMTAB_BLOCK"><tt>TYPE_SYMTAB_BLOCK</tt></a> &mdash; This describes the type symbol
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]754 table.</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]755<li>14 &mdash; <a href="#VALUE_SYMTAB_BLOCK"><tt>VALUE_SYMTAB_BLOCK</tt></a> &mdash; This describes a value symbol
Bill Wendlingbb7425f2009-04-04 22:27:03 +0000[diff] [blame]756 table.</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]757<li>15 &mdash; <a href="#METADATA_BLOCK"><tt>METADATA_BLOCK</tt></a> &mdash; This describes metadata items.</li>
758<li>16 &mdash; <a href="#METADATA_ATTACHMENT"><tt>METADATA_ATTACHMENT</tt></a> &mdash; This contains records associating metadata with function instruction values.</li>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]759</ul>
760
761</div>
762
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]763</div>
764
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]765<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]766<h3>
767 <a name="MODULE_BLOCK">MODULE_BLOCK Contents</a>
768</h3>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]769
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]770<div>
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]771
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]772<p>The <tt>MODULE_BLOCK</tt> block (id 8) is the top-level block for LLVM
773bitcode files, and each bitcode file must contain exactly one. In
774addition to records (described below) containing information
775about the module, a <tt>MODULE_BLOCK</tt> block may contain the
776following sub-blocks:
777</p>
778
779<ul>
780<li><a href="#BLOCKINFO"><tt>BLOCKINFO</tt></a></li>
781<li><a href="#PARAMATTR_BLOCK"><tt>PARAMATTR_BLOCK</tt></a></li>
782<li><a href="#TYPE_BLOCK"><tt>TYPE_BLOCK</tt></a></li>
783<li><a href="#TYPE_SYMTAB_BLOCK"><tt>TYPE_SYMTAB_BLOCK</tt></a></li>
784<li><a href="#VALUE_SYMTAB_BLOCK"><tt>VALUE_SYMTAB_BLOCK</tt></a></li>
785<li><a href="#CONSTANTS_BLOCK"><tt>CONSTANTS_BLOCK</tt></a></li>
786<li><a href="#FUNCTION_BLOCK"><tt>FUNCTION_BLOCK</tt></a></li>
787<li><a href="#METADATA_BLOCK"><tt>METADATA_BLOCK</tt></a></li>
788</ul>
789
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]790<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]791<h4><a name="MODULE_CODE_VERSION">MODULE_CODE_VERSION Record</a></h4>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]792
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]793<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]794
795<p><tt>[VERSION, version#]</tt></p>
796
797<p>The <tt>VERSION</tt> record (code 1) contains a single value
798indicating the format version. Only version 0 is supported at this
799time.</p>
800</div>
801
802<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]803<h4><a name="MODULE_CODE_TRIPLE">MODULE_CODE_TRIPLE Record</a></h4>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]804
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]805<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]806<p><tt>[TRIPLE, ...string...]</tt></p>
807
808<p>The <tt>TRIPLE</tt> record (code 2) contains a variable number of
809values representing the bytes of the <tt>target triple</tt>
810specification string.</p>
811</div>
812
813<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]814<h4><a name="MODULE_CODE_DATALAYOUT">MODULE_CODE_DATALAYOUT Record</a></h4>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]815
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]816<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]817<p><tt>[DATALAYOUT, ...string...]</tt></p>
818
819<p>The <tt>DATALAYOUT</tt> record (code 3) contains a variable number of
820values representing the bytes of the <tt>target datalayout</tt>
821specification string.</p>
822</div>
823
824<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]825<h4><a name="MODULE_CODE_ASM">MODULE_CODE_ASM Record</a></h4>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]826
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]827<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]828<p><tt>[ASM, ...string...]</tt></p>
829
830<p>The <tt>ASM</tt> record (code 4) contains a variable number of
831values representing the bytes of <tt>module asm</tt> strings, with
832individual assembly blocks separated by newline (ASCII 10) characters.</p>
833</div>
834
835<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]836<h4><a name="MODULE_CODE_SECTIONNAME">MODULE_CODE_SECTIONNAME Record</a></h4>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]837
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]838<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]839<p><tt>[SECTIONNAME, ...string...]</tt></p>
840
841<p>The <tt>SECTIONNAME</tt> record (code 5) contains a variable number
842of values representing the bytes of a single section name
843string. There should be one <tt>SECTIONNAME</tt> record for each
844section name referenced (e.g., in global variable or function
845<tt>section</tt> attributes) within the module. These records can be
846referenced by the 1-based index in the <i>section</i> fields of
847<tt>GLOBALVAR</tt> or <tt>FUNCTION</tt> records.</p>
848</div>
849
850<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]851<h4><a name="MODULE_CODE_DEPLIB">MODULE_CODE_DEPLIB Record</a></h4>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]852
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]853<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]854<p><tt>[DEPLIB, ...string...]</tt></p>
855
856<p>The <tt>DEPLIB</tt> record (code 6) contains a variable number of
857values representing the bytes of a single dependent library name
858string, one of the libraries mentioned in a <tt>deplibs</tt>
859declaration. There should be one <tt>DEPLIB</tt> record for each
860library name referenced.</p>
861</div>
862
863<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]864<h4><a name="MODULE_CODE_GLOBALVAR">MODULE_CODE_GLOBALVAR Record</a></h4>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]865
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]866<div>
Hans Wennborgce718ff2012-06-23 11:37:03 +0000[diff] [blame^]867<p><tt>[GLOBALVAR, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal, unnamed_addr]</tt></p>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]868
869<p>The <tt>GLOBALVAR</tt> record (code 7) marks the declaration or
870definition of a global variable. The operand fields are:</p>
871
872<ul>
873<li><i>pointer type</i>: The type index of the pointer type used to point to
874this global variable</li>
875
876<li><i>isconst</i>: Non-zero if the variable is treated as constant within
877the module, or zero if it is not</li>
878
879<li><i>initid</i>: If non-zero, the value index of the initializer for this
880variable, plus 1.</li>
881
882<li><a name="linkage"><i>linkage</i></a>: An encoding of the linkage
883type for this variable:
884 <ul>
885 <li><tt>external</tt>: code 0</li>
886 <li><tt>weak</tt>: code 1</li>
887 <li><tt>appending</tt>: code 2</li>
888 <li><tt>internal</tt>: code 3</li>
889 <li><tt>linkonce</tt>: code 4</li>
890 <li><tt>dllimport</tt>: code 5</li>
891 <li><tt>dllexport</tt>: code 6</li>
892 <li><tt>extern_weak</tt>: code 7</li>
893 <li><tt>common</tt>: code 8</li>
894 <li><tt>private</tt>: code 9</li>
895 <li><tt>weak_odr</tt>: code 10</li>
896 <li><tt>linkonce_odr</tt>: code 11</li>
897 <li><tt>available_externally</tt>: code 12</li>
898 <li><tt>linker_private</tt>: code 13</li>
899 </ul>
900</li>
901
902<li><i>alignment</i>: The logarithm base 2 of the variable's requested
903alignment, plus 1</li>
904
905<li><i>section</i>: If non-zero, the 1-based section index in the
906table of <a href="#MODULE_CODE_SECTIONNAME">MODULE_CODE_SECTIONNAME</a>
907entries.</li>
908
909<li><a name="visibility"><i>visibility</i></a>: If present, an
910encoding of the visibility of this variable:
911 <ul>
912 <li><tt>default</tt>: code 0</li>
913 <li><tt>hidden</tt>: code 1</li>
914 <li><tt>protected</tt>: code 2</li>
915 </ul>
916</li>
917
Hans Wennborgce718ff2012-06-23 11:37:03 +0000[diff] [blame^]918<li><i>threadlocal</i>: If present, an encoding of the thread local storage
919mode of the variable:
920 <ul>
921 <li><tt>not thread local</tt>: code 0</li>
922 <li><tt>thread local; default TLS model</tt>: code 1</li>
923 <li><tt>localdynamic</tt>: code 2</li>
924 <li><tt>initialexec</tt>: code 3</li>
925 <li><tt>localexec</tt>: code 4</li>
926 </ul>
927</li>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]928
Rafael Espindolabea46262011-01-08 16:42:36 +0000[diff] [blame]929<li><i>unnamed_addr</i>: If present and non-zero, indicates that the variable
Bill Wendling90464132011-04-08 21:43:08 +0000[diff] [blame]930has <tt>unnamed_addr</tt></li>
Rafael Espindolabea46262011-01-08 16:42:36 +0000[diff] [blame]931
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]932</ul>
933</div>
934
935<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]936<h4><a name="MODULE_CODE_FUNCTION">MODULE_CODE_FUNCTION Record</a></h4>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]937
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]938<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]939
940<p><tt>[FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc]</tt></p>
941
942<p>The <tt>FUNCTION</tt> record (code 8) marks the declaration or
943definition of a function. The operand fields are:</p>
944
945<ul>
946<li><i>type</i>: The type index of the function type describing this function</li>
947
948<li><i>callingconv</i>: The calling convention number:
949 <ul>
950 <li><tt>ccc</tt>: code 0</li>
951 <li><tt>fastcc</tt>: code 8</li>
952 <li><tt>coldcc</tt>: code 9</li>
953 <li><tt>x86_stdcallcc</tt>: code 64</li>
954 <li><tt>x86_fastcallcc</tt>: code 65</li>
955 <li><tt>arm_apcscc</tt>: code 66</li>
956 <li><tt>arm_aapcscc</tt>: code 67</li>
957 <li><tt>arm_aapcs_vfpcc</tt>: code 68</li>
958 </ul>
959</li>
960
961<li><i>isproto</i>: Non-zero if this entry represents a declaration
962rather than a definition</li>
963
964<li><i>linkage</i>: An encoding of the <a href="#linkage">linkage type</a>
965for this function</li>
966
967<li><i>paramattr</i>: If nonzero, the 1-based parameter attribute index
968into the table of <a href="#PARAMATTR_CODE_ENTRY">PARAMATTR_CODE_ENTRY</a>
969entries.</li>
970
971<li><i>alignment</i>: The logarithm base 2 of the function's requested
972alignment, plus 1</li>
973
974<li><i>section</i>: If non-zero, the 1-based section index in the
975table of <a href="#MODULE_CODE_SECTIONNAME">MODULE_CODE_SECTIONNAME</a>
976entries.</li>
977
978<li><i>visibility</i>: An encoding of the <a href="#visibility">visibility</a>
979 of this function</li>
980
981<li><i>gc</i>: If present and nonzero, the 1-based garbage collector
982index in the table of
983<a href="#MODULE_CODE_GCNAME">MODULE_CODE_GCNAME</a> entries.</li>
Rafael Espindolabea46262011-01-08 16:42:36 +0000[diff] [blame]984
985<li><i>unnamed_addr</i>: If present and non-zero, indicates that the function
NAKAMURA Takumi4d6deb02011-04-09 09:51:57 +0000[diff] [blame]986has <tt>unnamed_addr</tt></li>
Rafael Espindolabea46262011-01-08 16:42:36 +0000[diff] [blame]987
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]988</ul>
989</div>
990
991<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]992<h4><a name="MODULE_CODE_ALIAS">MODULE_CODE_ALIAS Record</a></h4>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]993
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]994<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]995
996<p><tt>[ALIAS, alias type, aliasee val#, linkage, visibility]</tt></p>
997
998<p>The <tt>ALIAS</tt> record (code 9) marks the definition of an
999alias. The operand fields are</p>
1000
1001<ul>
1002<li><i>alias type</i>: The type index of the alias</li>
1003
1004<li><i>aliasee val#</i>: The value index of the aliased value</li>
1005
1006<li><i>linkage</i>: An encoding of the <a href="#linkage">linkage type</a>
1007for this alias</li>
1008
1009<li><i>visibility</i>: If present, an encoding of the
1010<a href="#visibility">visibility</a> of the alias</li>
1011
1012</ul>
1013</div>
1014
1015<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1016<h4><a name="MODULE_CODE_PURGEVALS">MODULE_CODE_PURGEVALS Record</a></h4>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1017
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1018<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1019<p><tt>[PURGEVALS, numvals]</tt></p>
1020
1021<p>The <tt>PURGEVALS</tt> record (code 10) resets the module-level
1022value list to the size given by the single operand value. Module-level
1023value list items are added by <tt>GLOBALVAR</tt>, <tt>FUNCTION</tt>,
1024and <tt>ALIAS</tt> records. After a <tt>PURGEVALS</tt> record is seen,
1025new value indices will start from the given <i>numvals</i> value.</p>
1026</div>
1027
1028<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1029<h4><a name="MODULE_CODE_GCNAME">MODULE_CODE_GCNAME Record</a></h4>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1030
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1031<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1032<p><tt>[GCNAME, ...string...]</tt></p>
1033
1034<p>The <tt>GCNAME</tt> record (code 11) contains a variable number of
1035values representing the bytes of a single garbage collector name
1036string. There should be one <tt>GCNAME</tt> record for each garbage
1037collector name referenced in function <tt>gc</tt> attributes within
1038the module. These records can be referenced by 1-based index in the <i>gc</i>
1039fields of <tt>FUNCTION</tt> records.</p>
1040</div>
1041
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1042</div>
1043
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1044<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1045<h3>
1046 <a name="PARAMATTR_BLOCK">PARAMATTR_BLOCK Contents</a>
1047</h3>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1048
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1049<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1050
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1051<p>The <tt>PARAMATTR_BLOCK</tt> block (id 9) contains a table of
1052entries describing the attributes of function parameters. These
1053entries are referenced by 1-based index in the <i>paramattr</i> field
1054of module block <a name="MODULE_CODE_FUNCTION"><tt>FUNCTION</tt></a>
1055records, or within the <i>attr</i> field of function block <a
1056href="#FUNC_CODE_INST_INVOKE"><tt>INST_INVOKE</tt></a> and <a
1057href="#FUNC_CODE_INST_CALL"><tt>INST_CALL</tt></a> records.</p>
1058
1059<p>Entries within <tt>PARAMATTR_BLOCK</tt> are constructed to ensure
1060that each is unique (i.e., no two indicies represent equivalent
1061attribute lists). </p>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1062
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1063<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1064<h4><a name="PARAMATTR_CODE_ENTRY">PARAMATTR_CODE_ENTRY Record</a></h4>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1065
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1066<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1067
1068<p><tt>[ENTRY, paramidx0, attr0, paramidx1, attr1...]</tt></p>
1069
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1070<p>The <tt>ENTRY</tt> record (code 1) contains an even number of
1071values describing a unique set of function parameter attributes. Each
1072<i>paramidx</i> value indicates which set of attributes is
1073represented, with 0 representing the return value attributes,
10740xFFFFFFFF representing function attributes, and other values
1075representing 1-based function parameters. Each <i>attr</i> value is a
1076bitmap with the following interpretation:
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1077</p>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1078
1079<ul>
1080<li>bit 0: <tt>zeroext</tt></li>
1081<li>bit 1: <tt>signext</tt></li>
1082<li>bit 2: <tt>noreturn</tt></li>
1083<li>bit 3: <tt>inreg</tt></li>
1084<li>bit 4: <tt>sret</tt></li>
1085<li>bit 5: <tt>nounwind</tt></li>
1086<li>bit 6: <tt>noalias</tt></li>
1087<li>bit 7: <tt>byval</tt></li>
1088<li>bit 8: <tt>nest</tt></li>
1089<li>bit 9: <tt>readnone</tt></li>
1090<li>bit 10: <tt>readonly</tt></li>
1091<li>bit 11: <tt>noinline</tt></li>
1092<li>bit 12: <tt>alwaysinline</tt></li>
1093<li>bit 13: <tt>optsize</tt></li>
1094<li>bit 14: <tt>ssp</tt></li>
1095<li>bit 15: <tt>sspreq</tt></li>
1096<li>bits 16&ndash;31: <tt>align <var>n</var></tt></li>
1097<li>bit 32: <tt>nocapture</tt></li>
1098<li>bit 33: <tt>noredzone</tt></li>
1099<li>bit 34: <tt>noimplicitfloat</tt></li>
1100<li>bit 35: <tt>naked</tt></li>
1101<li>bit 36: <tt>inlinehint</tt></li>
1102<li>bits 37&ndash;39: <tt>alignstack <var>n</var></tt>, represented as
1103the logarithm base 2 of the requested alignment, plus 1</li>
1104</ul>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1105</div>
1106
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1107</div>
1108
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1109<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1110<h3>
1111 <a name="TYPE_BLOCK">TYPE_BLOCK Contents</a>
1112</h3>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1113
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1114<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1115
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1116<p>The <tt>TYPE_BLOCK</tt> block (id 10) contains records which
1117constitute a table of type operator entries used to represent types
1118referenced within an LLVM module. Each record (with the exception of
1119<a href="#TYPE_CODE_NUMENTRY"><tt>NUMENTRY</tt></a>) generates a
1120single type table entry, which may be referenced by 0-based index from
1121instructions, constants, metadata, type symbol table entries, or other
1122type operator records.
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1123</p>
1124
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1125<p>Entries within <tt>TYPE_BLOCK</tt> are constructed to ensure that
1126each entry is unique (i.e., no two indicies represent structurally
1127equivalent types). </p>
1128
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1129<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1130<h4><a name="TYPE_CODE_NUMENTRY">TYPE_CODE_NUMENTRY Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1131
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1132<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1133
1134<p><tt>[NUMENTRY, numentries]</tt></p>
1135
1136<p>The <tt>NUMENTRY</tt> record (code 1) contains a single value which
1137indicates the total number of type code entries in the type table of
1138the module. If present, <tt>NUMENTRY</tt> should be the first record
1139in the block.
1140</p>
1141</div>
1142
1143<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1144<h4><a name="TYPE_CODE_VOID">TYPE_CODE_VOID Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1145
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1146<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1147
1148<p><tt>[VOID]</tt></p>
1149
1150<p>The <tt>VOID</tt> record (code 2) adds a <tt>void</tt> type to the
1151type table.
1152</p>
1153</div>
1154
1155<!-- _______________________________________________________________________ -->
Tobias Grosser057beb82012-05-24 15:59:06 +0000[diff] [blame]1156<h4><a name="TYPE_CODE_HALF">TYPE_CODE_HALF Record</a></h4>
1157
1158<div>
1159
1160<p><tt>[HALF]</tt></p>
1161
1162<p>The <tt>HALF</tt> record (code 10) adds a <tt>half</tt> (16-bit
1163floating point) type to the type table.
1164</p>
1165</div>
1166
1167<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1168<h4><a name="TYPE_CODE_FLOAT">TYPE_CODE_FLOAT Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1169
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1170<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1171
1172<p><tt>[FLOAT]</tt></p>
1173
1174<p>The <tt>FLOAT</tt> record (code 3) adds a <tt>float</tt> (32-bit
1175floating point) type to the type table.
1176</p>
1177</div>
1178
1179<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1180<h4><a name="TYPE_CODE_DOUBLE">TYPE_CODE_DOUBLE Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1181
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1182<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1183
1184<p><tt>[DOUBLE]</tt></p>
1185
1186<p>The <tt>DOUBLE</tt> record (code 4) adds a <tt>double</tt> (64-bit
1187floating point) type to the type table.
1188</p>
1189</div>
1190
1191<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1192<h4><a name="TYPE_CODE_LABEL">TYPE_CODE_LABEL Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1193
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1194<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1195
1196<p><tt>[LABEL]</tt></p>
1197
1198<p>The <tt>LABEL</tt> record (code 5) adds a <tt>label</tt> type to
1199the type table.
1200</p>
1201</div>
1202
1203<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1204<h4><a name="TYPE_CODE_OPAQUE">TYPE_CODE_OPAQUE Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1205
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1206<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1207
1208<p><tt>[OPAQUE]</tt></p>
1209
1210<p>The <tt>OPAQUE</tt> record (code 6) adds an <tt>opaque</tt> type to
1211the type table. Note that distinct <tt>opaque</tt> types are not
1212unified.
1213</p>
1214</div>
1215
1216<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1217<h4><a name="TYPE_CODE_INTEGER">TYPE_CODE_INTEGER Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1218
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1219<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1220
1221<p><tt>[INTEGER, width]</tt></p>
1222
1223<p>The <tt>INTEGER</tt> record (code 7) adds an integer type to the
1224type table. The single <i>width</i> field indicates the width of the
1225integer type.
1226</p>
1227</div>
1228
1229<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1230<h4><a name="TYPE_CODE_POINTER">TYPE_CODE_POINTER Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1231
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1232<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1233
1234<p><tt>[POINTER, pointee type, address space]</tt></p>
1235
1236<p>The <tt>POINTER</tt> record (code 8) adds a pointer type to the
1237type table. The operand fields are</p>
1238
1239<ul>
1240<li><i>pointee type</i>: The type index of the pointed-to type</li>
1241
1242<li><i>address space</i>: If supplied, the target-specific numbered
1243address space where the pointed-to object resides. Otherwise, the
1244default address space is zero.
1245</li>
1246</ul>
1247</div>
1248
1249<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1250<h4><a name="TYPE_CODE_FUNCTION">TYPE_CODE_FUNCTION Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1251
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1252<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1253
1254<p><tt>[FUNCTION, vararg, ignored, retty, ...paramty... ]</tt></p>
1255
1256<p>The <tt>FUNCTION</tt> record (code 9) adds a function type to the
1257type table. The operand fields are</p>
1258
1259<ul>
1260<li><i>vararg</i>: Non-zero if the type represents a varargs function</li>
1261
1262<li><i>ignored</i>: This value field is present for backward
1263compatibility only, and is ignored</li>
1264
1265<li><i>retty</i>: The type index of the function's return type</li>
1266
1267<li><i>paramty</i>: Zero or more type indices representing the
1268parameter types of the function</li>
1269</ul>
1270
1271</div>
1272
1273<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1274<h4><a name="TYPE_CODE_STRUCT">TYPE_CODE_STRUCT Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1275
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1276<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1277
1278<p><tt>[STRUCT, ispacked, ...eltty...]</tt></p>
1279
1280<p>The <tt>STRUCT </tt> record (code 10) adds a struct type to the
1281type table. The operand fields are</p>
1282
1283<ul>
1284<li><i>ispacked</i>: Non-zero if the type represents a packed structure</li>
1285
1286<li><i>eltty</i>: Zero or more type indices representing the element
1287types of the structure</li>
1288</ul>
1289</div>
1290
1291<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1292<h4><a name="TYPE_CODE_ARRAY">TYPE_CODE_ARRAY Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1293
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1294<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1295
1296<p><tt>[ARRAY, numelts, eltty]</tt></p>
1297
1298<p>The <tt>ARRAY</tt> record (code 11) adds an array type to the type
1299table. The operand fields are</p>
1300
1301<ul>
1302<li><i>numelts</i>: The number of elements in arrays of this type</li>
1303
1304<li><i>eltty</i>: The type index of the array element type</li>
1305</ul>
1306</div>
1307
1308<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1309<h4><a name="TYPE_CODE_VECTOR">TYPE_CODE_VECTOR Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1310
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1311<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1312
1313<p><tt>[VECTOR, numelts, eltty]</tt></p>
1314
1315<p>The <tt>VECTOR</tt> record (code 12) adds a vector type to the type
1316table. The operand fields are</p>
1317
1318<ul>
1319<li><i>numelts</i>: The number of elements in vectors of this type</li>
1320
1321<li><i>eltty</i>: The type index of the vector element type</li>
1322</ul>
1323</div>
1324
1325<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1326<h4><a name="TYPE_CODE_X86_FP80">TYPE_CODE_X86_FP80 Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1327
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1328<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1329
1330<p><tt>[X86_FP80]</tt></p>
1331
1332<p>The <tt>X86_FP80</tt> record (code 13) adds an <tt>x86_fp80</tt> (80-bit
1333floating point) type to the type table.
1334</p>
1335</div>
1336
1337<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1338<h4><a name="TYPE_CODE_FP128">TYPE_CODE_FP128 Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1339
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1340<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1341
1342<p><tt>[FP128]</tt></p>
1343
1344<p>The <tt>FP128</tt> record (code 14) adds an <tt>fp128</tt> (128-bit
1345floating point) type to the type table.
1346</p>
1347</div>
1348
1349<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1350<h4><a name="TYPE_CODE_PPC_FP128">TYPE_CODE_PPC_FP128 Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1351
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1352<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1353
1354<p><tt>[PPC_FP128]</tt></p>
1355
1356<p>The <tt>PPC_FP128</tt> record (code 15) adds a <tt>ppc_fp128</tt>
1357(128-bit floating point) type to the type table.
1358</p>
1359</div>
1360
1361<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1362<h4><a name="TYPE_CODE_METADATA">TYPE_CODE_METADATA Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1363
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1364<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1365
1366<p><tt>[METADATA]</tt></p>
1367
1368<p>The <tt>METADATA</tt> record (code 16) adds a <tt>metadata</tt>
1369type to the type table.
1370</p>
1371</div>
1372
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1373</div>
1374
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1375<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1376<h3>
1377 <a name="CONSTANTS_BLOCK">CONSTANTS_BLOCK Contents</a>
1378</h3>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1379
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1380<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1381
1382<p>The <tt>CONSTANTS_BLOCK</tt> block (id 11) ...
1383</p>
1384
1385</div>
1386
1387
1388<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1389<h3>
1390 <a name="FUNCTION_BLOCK">FUNCTION_BLOCK Contents</a>
1391</h3>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1392
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1393<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1394
1395<p>The <tt>FUNCTION_BLOCK</tt> block (id 12) ...
1396</p>
1397
1398<p>In addition to the record types described below, a
1399<tt>FUNCTION_BLOCK</tt> block may contain the following sub-blocks:
1400</p>
1401
1402<ul>
1403<li><a href="#CONSTANTS_BLOCK"><tt>CONSTANTS_BLOCK</tt></a></li>
1404<li><a href="#VALUE_SYMTAB_BLOCK"><tt>VALUE_SYMTAB_BLOCK</tt></a></li>
1405<li><a href="#METADATA_ATTACHMENT"><tt>METADATA_ATTACHMENT</tt></a></li>
1406</ul>
1407
1408</div>
1409
1410
1411<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1412<h3>
1413 <a name="TYPE_SYMTAB_BLOCK">TYPE_SYMTAB_BLOCK Contents</a>
1414</h3>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1415
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1416<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1417
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1418<p>The <tt>TYPE_SYMTAB_BLOCK</tt> block (id 13) contains entries which
1419map between module-level named types and their corresponding type
1420indices.
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1421</p>
1422
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1423<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1424<h4><a name="TST_CODE_ENTRY">TST_CODE_ENTRY Record</a></h4>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1425
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1426<div>
Chris Lattner299f4242010-05-21 22:20:54 +0000[diff] [blame]1427
1428<p><tt>[ENTRY, typeid, ...string...]</tt></p>
1429
1430<p>The <tt>ENTRY</tt> record (code 1) contains a variable number of
1431values, with the first giving the type index of the designated type,
1432and the remaining values giving the character codes of the type
1433name. Each entry corresponds to a single named type.
1434</p>
1435</div>
1436
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1437</div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1438
1439<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1440<h3>
1441 <a name="VALUE_SYMTAB_BLOCK">VALUE_SYMTAB_BLOCK Contents</a>
1442</h3>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1443
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1444<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1445
1446<p>The <tt>VALUE_SYMTAB_BLOCK</tt> block (id 14) ...
1447</p>
1448
1449</div>
1450
1451
1452<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1453<h3>
1454 <a name="METADATA_BLOCK">METADATA_BLOCK Contents</a>
1455</h3>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1456
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1457<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1458
1459<p>The <tt>METADATA_BLOCK</tt> block (id 15) ...
1460</p>
1461
1462</div>
1463
1464
1465<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000[diff] [blame]1466<h3>
1467 <a name="METADATA_ATTACHMENT">METADATA_ATTACHMENT Contents</a>
1468</h3>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1469
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1470<div>
Chris Lattner5c303e82009-10-29 04:25:46 +0000[diff] [blame]1471
1472<p>The <tt>METADATA_ATTACHMENT</tt> block (id 16) ...
Chris Lattner69b3e402007-05-13 01:39:44 +0000[diff] [blame]1473</p>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]1474
1475</div>
1476
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000[diff] [blame]1477</div>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]1478
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]1479<!-- *********************************************************************** -->
1480<hr>
1481<address> <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
Misha Brukman44408702008-12-11 17:34:48 +0000[diff] [blame]1482 src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]1483<a href="http://validator.w3.org/check/referer"><img
Misha Brukman44408702008-12-11 17:34:48 +0000[diff] [blame]1484 src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
Chris Lattnere9ef4572007-05-12 03:23:40 +0000[diff] [blame]1485 <a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
NAKAMURA Takumib9a33632011-04-09 02:13:37 +0000[diff] [blame]1486<a href="http://llvm.org/">The LLVM Compiler Infrastructure</a><br>
Reid Spencer2c1ce4f2007-01-20 23:21:08 +0000[diff] [blame]1487Last modified: $Date$
1488</address>
1489</body>
1490</html>