summaryrefslogtreecommitdiffstats
path: root/llvm/docs/BytecodeFormat.html
diff options
context:
space:
mode:
authorReid Spencer <rspencer@reidspencer.com>2004-08-17 07:43:43 +0000
committerReid Spencer <rspencer@reidspencer.com>2004-08-17 07:43:43 +0000
commit0b85d03b57df85bdf1e75db1f60cab465fe95903 (patch)
tree7c03920d301252ec365bab34be13c175e0dc0745 /llvm/docs/BytecodeFormat.html
parent081854163134e63790b62399a32572ab123ca85a (diff)
downloadbcm5719-llvm-0b85d03b57df85bdf1e75db1f60cab465fe95903.tar.gz
bcm5719-llvm-0b85d03b57df85bdf1e75db1f60cab465fe95903.zip
Documented the removal of alignment in version 4 bytecode files (version 3
was released with LLVM 1.3). Alignment of fields can add severe size to certain kinds of functions (those with lots of long format instructions) so we decided to do away with alignment altogether in this bc version. llvm-svn: 15874
Diffstat (limited to 'llvm/docs/BytecodeFormat.html')
-rw-r--r--llvm/docs/BytecodeFormat.html28
1 files changed, 28 insertions, 0 deletions
diff --git a/llvm/docs/BytecodeFormat.html b/llvm/docs/BytecodeFormat.html
index 226cd9638be..b204c837695 100644
--- a/llvm/docs/BytecodeFormat.html
+++ b/llvm/docs/BytecodeFormat.html
@@ -1556,6 +1556,34 @@ describes the differences between that version and the one that <i>follows</i>.
</p>
</div>
<!-- _______________________________________________________________________ -->
+<div class="doc_subsection"><a name="vers12">Version 1.3 Differences From
+ 1.4</a></div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">Aligned Data</div>
+<div class="doc_text">
+ <p>In version 1.3, certain data items were aligned to 32-bit boundaries. In
+ version 1.4, alignment of data was done away with completely. The need for
+ alignment has gone away and the only thing it adds is bytecode file size
+ overhead. In most cases this overhead was small. However, in functions with
+ large numbers of format 0 instructions (GEPs and PHIs with lots of parameters)
+ or regular instructions with large valued operands (e.g. because there's just
+ a lot of instructions in the function) the overhead can be extreme. In one
+ test case, the overhead was 44,000 bytes (34% of the total file size).
+ Consequently in release 1.4, the decision was made to eliminate alignment
+ altogether.</p>
+ <p>In version 1.3 format, the following bytecode constructs were aligned (i.e.
+ they were followed by one to three bytes of padding):</p>
+ <ul>
+ <li>All blocks.</li>
+ <li>Instructions using the long format (format 0).</li>
+ <li>All call instructions that called a var args function.</li>
+ <li>The target triple (a string field at the end of the module block).</li>
+ <li>The version field (immediately following the signature).</li>
+ </ul>
+ <p>None of these constructs are aligned in version 1.4</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
<div class="doc_subsection"><a name="vers12">Version 1.2 Differences
From 1.3</a></div>
<!-- _______________________________________________________________________ -->
OpenPOWER on IntegriCloud