This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Mostly rewrite genrecog
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Richard Sandiford <richard dot sandiford at arm dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 29 Apr 2015 10:42:20 +0200
- Subject: Re: Mostly rewrite genrecog
- Authentication-results: sourceware.org; auth=none
- References: <87egn5yis1 dot fsf at e105548-lin dot cambridge dot arm dot com>
> I think it's been the case for a while that parallel builds of GCC tend
> to serialise around the compilation of insn-recog.c, especially with
> higher --enable-checking settings. This patch tries to speed that
> up by replacing most of genrecog with a new algorithm.
I can confirm this, especially with --enable-checking=rtl.
> Also, the code is all goto-based, which makes it rather hard to step
> through.
Do you mean the code in genrecog.c or the generated code in insn-recog.c?
> The patch deals with these as follows:
>
> 1. Detect subpatterns that differ only by mode, code and/or integer
> (e.g. unspec number) and split them out into a common routine.
>
> 2. Match the "shape" of the instruction first, in terms of codes,
> integers and vector lengths, and only then check the modes, predicates
> and dups. When checking the shape, handle SET_SRCs before SET_DESTs.
> In practice this seems to greatly reduce the amount of backtracking.
>
> 3. Have one local variable per rtx position. I tested the patch with
> and without the change and it helped a lot with rtl-checking builds
> without seeming to affect release builds much either way.
>
> As far as debuggability goes, the new code avoids gotos and just
> uses "natural" control flow.
See below.
> The headline stat is that a stage 3 --enable-checking=yes,rtl,df
> build of insn-recog.c on my box goes from 7m43s to 2m2s (using the
> same stage 2 compiler). The corresponding --enable-checking=release
> change is from 49s to 24s (less impressive, as expected).
The first figure is quite impressive, great work!
> PS. I've attached the new genrecog.c since the diff version is unreadable.
Small request: you didn't change a single line of the head comment, yet the
size of the file is doubled. Could you add a sketch of the algorithm to the
head comment, e.g. by copy-and-pasting the above part of your message?
The old code contained a couple of DEBUG_FUNCTIONs but the new one doesn't.
--
Eric Botcazou