[PING] Re: [PATCH 0/2] Embed driver within libgccjit

[David Malcolm <dmalcolm@redhat.com>]

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.