[LLVMdev] [PATCH / PROPOSAL] bitcode encoding that is ~15% smaller for large bitcode files...

[Rafael Espíndola]

> Thanks for taking a look!  I wasn't sure of better way to toggle this
> behavior at the module level vs the function level.  The options I toyed
> with were:
>
>   (a) bump MODULE_CODE_VERSION from 0 to 1
>   (b) add a new optional module code to identify the change
>   (c) stick with the approach in the first patch, which used a new function
> block ID value, then check that all the function blocks uniformly have the
> newer ID instead of mix of the old and new.
>
>
> for option (a) there hasn't been a version bump before(?) and I wasn't sure
> when that is appropriate.
> for option (b) it seems like it's really indicating a version change and not
> doing anything else, so could have been done more directly with (a)
> for option (c) it ends up creating a new block ID that overlaps with the
> existing function one and that would be first one to do that?
>
> Thanks again Duncan for the review, and Renato for the suggestion of looking
> into SLEB. Attached is an updated patch which toggles the change at the
> module level (done with option a), and uses signed VRBs for phis,

This is awesome! I tried it by creating a .ll of all of clang. Some sizes:

* clang.ll        490M
* clang.ll.gz   55M
* clang.ll.bz2 37M
* clang.ll.xz   27M

with the current bitcode:

* clang.bc      82M
* clang.bc.xz 27M

with the new bitcode:

* clang.bc 70M
* clang.bc.xz 26M

it looks like a nop run of opt also got a bit faster, from 10.451s to 10.176s.

+static void EmitSignedInt64(SmallVectorImpl<uint64_t> &Vals, uint64_t V) {

Please start function names with a lower case letter.

+EnableOldStyleFunctions("enable-old-style-functions",

Maybe something like use-abs-operands is a better name now that this
is a global setting, no?

> - Jan

Cheers,
Rafael