[LLVMdev] [PATCH / PROPOSAL] bitcode encoding that is ~15% smaller for large bitcode files...
jvoung at chromium.org
Thu Sep 27 16:07:37 PDT 2012
On Thu, Sep 27, 2012 at 2:57 AM, Renato Golin <rengolin at systemcall.org>wrote:
> On 26 September 2012 22:08, Jan Voung <jvoung at chromium.org> wrote:
> > I think most of the instructions operands are encoded as VBR(N)
> > for some N number of bits, and it seems to me that VBR(8) is like ULEB?
> > I think that the default N is 6 bits, but I haven't tried tweaking these
> > parameters.
> It has a similar purpose, but slightly different. SLEB (the signed
> version) wouldn't use the whole word for -1, since the sign expansion
> happens after the number is encoded to 7 bits package, so any negative
> number that can be represented using 7 bits would still be stored in a
Ah I see. It looks like LLVM's bitcode writer does have a signed version
of the VBRs, which is used for integer constants. I tried using that for
phis and added the data to the *second sheet* in the original
spreadsheet. See the tab "With SLEB-like Signed VBR for phi",
at the bottom.
It's certainly a bit better (1.3% uncompressed and 0.7% with gzip too),
but it's not always better, and I think it can still be done in a backward
I added numbers for what would happen if we didn't touch phis at all, too.
Finally, checked the average size of individual bc files from a build of
the llvm-test-suite (vs llvm-linked bitcode files), to make sure this isn't
really regressing sizes of small files. The average size of such
small bitcode object files is ~3.5% better. Didn't check compression
for that case though...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev