On Wed, 2018-11-14 at 09:49 +0000, Kyrill Tkachov wrote: > On 13/11/18 18:45, David Malcolm wrote: > > On Tue, 2018-11-13 at 17:58 +0000, Kyrill Tkachov wrote: > > > 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 > > > > Sorry about that. Does the following patch fix the build for you? > > Yes, that fixes it. > Thanks David! > > Kyrill
Thanks; I've committed it to trunk as r266156. Dave
