Re: Long compile time of 'insn-extract.c'

[Iain Sandoe <idsandoe at googlemail dot com>]

Hi Thomas,

> On 18 Jun 2019, at 17:40, Thomas Schwinge <thomas@codesourcery.com> wrote:
> 

> I normally don't pay too much attention to how GCC builds proceed, but
> here, I was waiting for it to complete...  ;-)
> 
> Doing a native bootstrap build on x86_64-pc-linux-gnu, with
> '--enable-checking=yes,extra,df,fold,rtl' (is that excessive, maybe?), I
> just noticed that stage 2 (thus actually '-fno-checking') build of
> 'insn-extract.c' took more than 80 min to complete (with 1.3 GiB RAM
> resident, which seems "reasonable").
> 
> I know we have some such issues compiling GCC's large generated files,
> but I don't think I noticed that one being so much slower than the
> others.  In terms of file size (which doesn't say too much, I
> understand), it's with 432 KiB not exactly small, but not exactly huge
> either: 'insn-automata.c' occupies 11 MiB, and in the '-j16' build on
> "Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz" completed much earlier.
> 
> I do notice that 'insn-extract.c' is special in that it contains exactly
> one function, containing one huge 'switch' statement at its top level.
> 
> Is this maybe an issue/regression that somebody else also has noticed
> (recently?), and/or worth investigating?

It also has a habit of OOMing on i686-darwin10 when built with
—enable-checking=yes,rtl,tree 
(O1 is sufficient to suppress that issue tho).  I hadn’t paid too much attention to
the time taken, just that it breaks bootstrap with that checking recipe.


Iain.