> 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
