On 11/9/18 10:51 AM, David Malcolm wrote:
> One of the concerns noted at Cauldron about -fsave-optimization-record
> was the size of the output files.
>
> This file implements compression of the -fsave-optimization-record
> output, using zlib.
>
> I did some before/after testing of this patch, using SPEC 2017's
> 502.gcc_r with -O3, looking at the sizes of the generated
> FILENAME.opt-record.json[.gz] files.
>
> The largest file was for insn-attrtab.c:
> before: 171736285 bytes (164M)
> after: 5304015 bytes (5.1M)
>
> Smallest file was for vasprintf.c:
> before: 30567 bytes
> after: 4485 bytes
>
> Median file by size before was lambda-mat.c:
> before: 2266738 bytes (2.2M)
> after: 75988 bytes (15K)
>
> Total of all files in the benchmark:
> before: 2041720713 bytes (1.9G)
> after: 66870770 bytes (63.8M)
>
> ...so clearly compression is a big win in terms of file size, at the
> cost of making the files slightly more awkward to work with. [1]
> I also wonder if we want to support any pre-filtering of the output
> (FWIW roughly half of the biggest file seems to be "Adding assert for "
> messages from tree-vrp.c).
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> OK for trunk?
>
> [1] I've updated my optrecord.py module to deal with this, which
> simplifies things; it's still not clear to me if that should live
> in "contrib/" or not.
>
> gcc/ChangeLog:
> * doc/invoke.texi (-fsave-optimization-record): Note that the
> output is compressed.
> * optinfo-emit-json.cc: Include <zlib.h>.
> (optrecord_json_writer::write): Compress the output.
OK.
jeff