Hi David, On 09/11/18 21:00, Jeff Law wrote:
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? >
So does this now add a dependency on zlib? I can't build GCC on my aarch64-none-linux machine after this patch due to a missing zlib.h. I see there's a zlib in the top-level GCC tree. Is that build/used during the GCC build itself? Thanks, Kyrill
> [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
