On Fri, Nov 18, 2022 at 12:06 PM Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > > 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.
Yes I know which is why I am ok with waiting for GCC 14 really. I decided to try to clear out some of the old bug reports assigned to myself and this one was one of the oldest and also one of the easiest to do. > > 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. I recorded some of the timings in the bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840#c14 Summary is using the same compiler as a base, compiling generic-match.cc is now ~7% faster. I have not looked into why but I can only assume it is due to less debug info and less basic blocks. I assume without checking enabled (or rather release checking) on the sources, I can only assume the speedup is not going to be seen. Most of the constant reads are in the checking part of the code. Thanks, Andrew Pinski > > > Jeff
