On Thu, 2015-08-06 at 10:52 -0400, David Malcolm wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00355.html
In particular, I'm hoping for review of patch 1, which provides a way to clean up state within the driver code (patch 2 uses this from libgccjit to embed it in-process, rather that via pex, achieving a speedup and enabling followup improvements). > The attached two patches are an updated version of this patch > sent in June: > https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00123.html > "[PATCH 02/16] gcc: Embed the driver in-process within libgccjit" > > (an updated version of [patch 01/16] from that kit is in trunk as of > r226530; https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02713.html) > > They provide a modest speedup of jit.dg/test-benchmark.c and hence > are useful in their own right: > > Median time taken for 100 in-process compiles (lower is better) over > multiple runs, showing mean within each run: > > Control build of r226530, with pex-execution of driver binary: > optlevel 0: 6.210s (0.062s per iteration) > optlevel 1: 6.990s (0.070s per iteration) > optlevel 2: 7.240s (0.072s per iteration) > optlevel 3: 9.010s (0.090s per iteration) > > With these patches, embedding the driver: > optlevel 0: 6.020s (0.060s per iteration) > optlevel 1: 6.720s (0.067s per iteration) > optlevel 2: 7.020s (0.070s per iteration) > optlevel 3: 8.660s (0.087s per iteration) > > They are also a prerequisite for some of the much larger speedups > proposed in the followup patches sent in June. > > I've split them out into the driver part (patch 1) and the jit-specific > part (patch 2) for ease of review.