In all the simple code cases I've examined by hand so far, empty compaction tables are defined for the functions that remain after full linking and inlining (in both the cases below, a single function remains). Case #1 ----- int main( void ) { return( 0 ); } ----- Case #2 ----- #include <stdio.h> int main( void ) { puts( "Hello world!" ); return( 0 ); } -----
Created attachment 168 [details] Bytecode For Robert's First Example This bytecode file has an empty compaction table in it.
Created attachment 169 [details] Bytecode For Robert's Second Example This also has an empty compaction table in it.
Verified that this is a bug. The empty compaction table is not being elided.
This is a regression introduced in release 1.3 with the Type != Value change. The problem is that the compaction table now consists of a Type list followed by a set of planes of Values. Previously, it had just the planes of Values (because Types were Values). Because the type list must write a 0 byte to indicate there are no types, the block is not zero length and thus not automatically elided, even if there are no planes of Values. The fix for this isn't straight foward. You don't know that the planes of Values won't all be omitted until you traverse them all (the compaction table can be full of empty planes if that makes any sense). I'll look into this when I have time. It only affects the size of the bytecode file, not the quality of it.
The problem has been resolved by detecting an empty compaction table before it is written out. Patches are here: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040823/017525.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040823/017526.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040823/017527.html