On 11/18/22 11:05, apinski--- via Gcc-patches wrote:
From: Andrew Pinski <apin...@marvell.com>

Since we use C++11 by default now, we can
use constexpr for some const decls in tree-core.h.

This patch does that and it allows for better optimizations
of GCC code with checking enabled and without LTO.

For an example generic-match.cc compiling is speed up due
to the less number of basic blocks and less debugging info
produced. I did not check the speed of compiling the same source
but rather the speed of compiling the old vs new sources here
(but with the same compiler base).

The small slow down in the parsing of the arrays in each TU
is migrated by a speed up in how much code/debugging info
is produced in the end.

Note I looked at generic-match.cc since it is one of the
compiling sources which causes parallel building to stall and
I wanted to speed it up.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Or should this wait until GCC 13 branches off?

gcc/ChangeLog:

        PR middle-end/14840
        * tree-core.h (tree_code_type): Constexprify
        by including all-tree.def.
        (tree_code_length): Likewise.
        * tree.cc (tree_code_type): Remove.
        (tree_code_length): Remove.

I would have preferred this a week ago :-)   And if it was just const-ifying, I'd ACK it without hesitation.

Can you share any of the build-time speedups you're seeing, even if they're not perfect.  It'd help to get a sense of the potential gain here and whether or not there's enough gain to gate it into gcc-13 or have it wait for gcc-14.


And if we can improve the compile-time of the files generated by match.pd, that's a win.  It's definitely a serialization point -- it becomes *painfully* obvious when doing a bootstrap using qemu, when that file takes 1-2hrs after everything else has finished.


Jeff

Reply via email to