| Message ID | 1542134724-27842-1-git-send-email-dmalcolm@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add missing ZLIBINC to CFLAGS-optinfo-emit-json.o | expand |
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 > gcc/ChangeLog: > * Makefile.in (CFLAGS-optinfo-emit-json.o): Add $(ZLIBINC). > --- > gcc/Makefile.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/Makefile.in b/gcc/Makefile.in > index 16c9ed6..1e8a311 100644 > --- a/gcc/Makefile.in > +++ b/gcc/Makefile.in > @@ -2233,7 +2233,7 @@ s-bversion: BASE-VER > $(STAMP) s-bversion > > CFLAGS-toplev.o += -DTARGET_NAME=\"$(target_noncanonical)\" > -CFLAGS-optinfo-emit-json.o += -DTARGET_NAME=\"$(target_noncanonical)\" > +CFLAGS-optinfo-emit-json.o += -DTARGET_NAME=\"$(target_noncanonical)\" $(ZLIBINC) > > pass-instances.def: $(srcdir)/passes.def $(PASSES_EXTRA) \ > $(srcdir)/gen-pass-instances.awk
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
diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 16c9ed6..1e8a311 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -2233,7 +2233,7 @@ s-bversion: BASE-VER $(STAMP) s-bversion CFLAGS-toplev.o += -DTARGET_NAME=\"$(target_noncanonical)\" -CFLAGS-optinfo-emit-json.o += -DTARGET_NAME=\"$(target_noncanonical)\" +CFLAGS-optinfo-emit-json.o += -DTARGET_NAME=\"$(target_noncanonical)\" $(ZLIBINC) pass-instances.def: $(srcdir)/passes.def $(PASSES_EXTRA) \ $(srcdir)/gen-pass-instances.awk