From: Reid Spencer Date: Tue, 17 Aug 2004 07:43:43 +0000 (+0000) Subject: Documented the removal of alignment in version 4 bytecode files (version 3 X-Git-Url: http://plrg.eecs.uci.edu/git/?a=commitdiff_plain;h=cf549e1f32cbeb19bcb846320a8ff0226dd9d3cb;p=oota-llvm.git 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@15874 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/docs/BytecodeFormat.html b/docs/BytecodeFormat.html index 226cd9638be..b204c837695 100644 --- a/docs/BytecodeFormat.html +++ b/docs/BytecodeFormat.html @@ -1555,6 +1555,34 @@ section here describes the differences between that version and the one that follows.

+ +
Version 1.3 Differences From + 1.4
+ +
Aligned Data
+
+

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.

+

In version 1.3 format, the following bytecode constructs were aligned (i.e. + they were followed by one to three bytes of padding):

+ +

None of these constructs are aligned in version 1.4

+
+
Version 1.2 Differences From 1.3