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 an attachment (id=168) [details]
Bytecode For Robert's First Example

This bytecode file has an empty compaction table in it.

Created an attachment (id=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