This is a feature, not a drawback. Aggregate types for C-like languages tend to bloat the code for no real optimization benefit. See the comparison between LLVM IR and Emscripten-generated JavaScript here: http://mozakai.blogspot.com/2011/11/code-size-when-compiling...
(Of course, for GC'd languages, we will need aggregate types.)
Actually, aggregate types help optimization a lot in C like languages, because it makes it easy to disambiguate between accesses based on offsets. IE two random int pointers is not helpful, two accesses to fields through a pointer to a structure is helpful.
In non-pointer C like languages, yes, they are mostly a burden.
The reason the .bc in the example given is large is because the toolchain does not try to optimize at all for intermediate .bc size. Final .bc size should be relatively sane.
I don't see that I can download the .bc files from that blog post, but I'm mildly curious if they are before or after running opt, because if i had to guess, based on the fact that it gzip's well, i'd guess it's before running opt on it.
Sorry, I should have been clearer: the types are definitely helpful for optimization. For distribution I'm not so sure. The IR-level optimizations where types really help (scalar replacement of aggregates, etc) are already run before the code hits the wire.
It depends.
For distribution where you know you will never optimize at runtime, yes, it's completely worthless.
But part of the reason you may find it worthless is because none of these VM's really perform the strong alias analysis and load/store redundancy removal techniques you could perform at runtime.
(Of course, for GC'd languages, we will need aggregate types.)