* [Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
[not found] <bug-14840-4@http.gcc.gnu.org/bugzilla/>
@ 2011-03-22 7:37 ` froydnj at gcc dot gnu.org
2014-01-04 2:24 ` pinskia at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: froydnj at gcc dot gnu.org @ 2011-03-22 7:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
Nathan Froyd <froydnj at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |froydnj at gcc dot gnu.org
Resolution| |WONTFIX
--- Comment #10 from Nathan Froyd <froydnj at gcc dot gnu.org> 2011-03-22 00:29:53 UTC ---
This bug has been open for almost five years. When I tried Andrew's posted
patch, I think bootstrap slowed down slightly--possibly because of the extra
parsing and logic in TREE_CODE_CLASS?
Anyway, LTO should take care of this. I'm going to close this; if somebody
wants to keep the bug around for posterity, feel free to reopen.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
[not found] <bug-14840-4@http.gcc.gnu.org/bugzilla/>
2011-03-22 7:37 ` [Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself froydnj at gcc dot gnu.org
@ 2014-01-04 2:24 ` pinskia at gcc dot gnu.org
2021-09-06 7:02 ` pinskia at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2014-01-04 2:24 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |NEW
Resolution|WONTFIX |---
--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Reopening due to GET_MODE_SIZE getting the same attention.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
[not found] <bug-14840-4@http.gcc.gnu.org/bugzilla/>
2011-03-22 7:37 ` [Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself froydnj at gcc dot gnu.org
2014-01-04 2:24 ` pinskia at gcc dot gnu.org
@ 2021-09-06 7:02 ` pinskia at gcc dot gnu.org
2022-11-18 4:15 ` pinskia at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-09-06 7:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
since we require C++11 now, shouldn't they be constexpr now?
I will try doing that in the next couple of weeks.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
[not found] <bug-14840-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2021-09-06 7:02 ` pinskia at gcc dot gnu.org
@ 2022-11-18 4:15 ` pinskia at gcc dot gnu.org
2022-11-18 4:39 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-11-18 4:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #8839|0 |1
is obsolete| |
--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 53921
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53921&action=edit
C++11 constexprify these variables
This "constexpr"ify these variables. I am going to do a bootstrap/test on it
(building cc1 cc1plus works so ...).
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
[not found] <bug-14840-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2022-11-18 4:15 ` pinskia at gcc dot gnu.org
@ 2022-11-18 4:39 ` pinskia at gcc dot gnu.org
2022-11-18 5:02 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-11-18 4:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Compile time using the same base compiler (without the patch and with
--enable-checking=yes)
Without the patch:
apinski@xeond:~/src/upstream-gcc/gcc/objdir/gcc$ time make -j16 generic-match.o
CXXFLAGS="-O2 -g"
/home/apinski/src/upstream-gcc/gcc/objdir/./prev-gcc/xg++
-B/home/apinski/src/upstream-gcc/gcc/objdir/./prev-gcc/
-B/home/apinski/upstream-gcc/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/apinski/src/upstream-gcc/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/apinski/src/upstream-gcc/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/home/apinski/src/upstream-gcc/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/home/apinski/src/upstream-gcc/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/apinski/src/upstream-gcc/gcc/libstdc++-v3/libsupc++
-L/home/apinski/src/upstream-gcc/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/apinski/src/upstream-gcc/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c -O2 -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-Wno-unused -DHAVE_CONFIG_H -I. -I. -I/home/apinski/src/upstream-gcc/gcc/gcc
-I/home/apinski/src/upstream-gcc/gcc/gcc/.
-I/home/apinski/src/upstream-gcc/gcc/gcc/../include
-I/home/apinski/src/upstream-gcc/gcc/gcc/../libcpp/include
-I/home/apinski/src/upstream-gcc/gcc/gcc/../libcody
-I/home/apinski/src/upstream-gcc/gcc/objdir/./gmp
-I/home/apinski/src/upstream-gcc/gcc/gmp
-I/home/apinski/src/upstream-gcc/gcc/objdir/./mpfr/src
-I/home/apinski/src/upstream-gcc/gcc/mpfr/src
-I/home/apinski/src/upstream-gcc/gcc/mpc/src
-I/home/apinski/src/upstream-gcc/gcc/gcc/../libdecnumber
-I/home/apinski/src/upstream-gcc/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/apinski/src/upstream-gcc/gcc/gcc/../libbacktrace
-I/home/apinski/src/upstream-gcc/gcc/objdir/./isl/include
-I/home/apinski/src/upstream-gcc/gcc/isl/include -o generic-match.o -MT
generic-match.o -MMD -MP -MF ./.deps/generic-match.TPo generic-match.cc
real 1m48.703s
user 1m47.137s
sys 0m1.458s
with the patch:
apinski@xeond:~/src/upstream-gcc/gcc/objdir/gcc$ time make -j16 generic-match.o
CXXFLAGS="-O2 -g"
/home/apinski/src/upstream-gcc/gcc/objdir/./prev-gcc/xg++
-B/home/apinski/src/upstream-gcc/gcc/objdir/./prev-gcc/
-B/home/apinski/upstream-gcc/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/apinski/src/upstream-gcc/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/apinski/src/upstream-gcc/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/home/apinski/src/upstream-gcc/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/home/apinski/src/upstream-gcc/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/apinski/src/upstream-gcc/gcc/libstdc++-v3/libsupc++
-L/home/apinski/src/upstream-gcc/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/apinski/src/upstream-gcc/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c -O2 -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-Wno-unused -DHAVE_CONFIG_H -I. -I. -I/home/apinski/src/upstream-gcc/gcc/gcc
-I/home/apinski/src/upstream-gcc/gcc/gcc/.
-I/home/apinski/src/upstream-gcc/gcc/gcc/../include
-I/home/apinski/src/upstream-gcc/gcc/gcc/../libcpp/include
-I/home/apinski/src/upstream-gcc/gcc/gcc/../libcody
-I/home/apinski/src/upstream-gcc/gcc/objdir/./gmp
-I/home/apinski/src/upstream-gcc/gcc/gmp
-I/home/apinski/src/upstream-gcc/gcc/objdir/./mpfr/src
-I/home/apinski/src/upstream-gcc/gcc/mpfr/src
-I/home/apinski/src/upstream-gcc/gcc/mpc/src
-I/home/apinski/src/upstream-gcc/gcc/gcc/../libdecnumber
-I/home/apinski/src/upstream-gcc/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/apinski/src/upstream-gcc/gcc/gcc/../libbacktrace
-I/home/apinski/src/upstream-gcc/gcc/objdir/./isl/include
-I/home/apinski/src/upstream-gcc/gcc/isl/include -o generic-match.o -MT
generic-match.o -MMD -MP -MF ./.deps/generic-match.TPo generic-match.cc
real 1m41.673s
user 1m39.165s
sys 0m1.462s
So slightly faster (~7%). I wonder if it is because there is less debug info
produced.
generic-match.cc is the best case of what this can do really.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
[not found] <bug-14840-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2022-11-18 4:39 ` pinskia at gcc dot gnu.org
@ 2022-11-18 5:02 ` pinskia at gcc dot gnu.org
2022-11-19 17:10 ` cvs-commit at gcc dot gnu.org
2022-11-19 17:11 ` pinskia at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-11-18 5:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looking at the -fdump-tree-optimized for generic-match.cc (-O2 -g) in terms of
lines, we get:
832068 before
718872 after
That is 17% less lines. That is nice improvments. Majority is debugging info
for arguments which are no longer used any more.
A good example is:
# DEBUG BEGIN_STMT
- # DEBUG __t => _39
- # DEBUG __f => "generic-match.cc"
- # DEBUG __l => 8705
- # DEBUG __g => "generic_simplify_127"
- # DEBUG INLINE_ENTRY non_type_check
- # DEBUG BEGIN_STMT
- _273 = tree_code_type[26];
- if (_273 == 2)
- goto <bb 38>; [0.00%]
- else
- goto <bb 39>; [100.00%]
-
- <bb 38> [count: 0]:
- # DEBUG BEGIN_STMT
- tree_not_class_check_failed (_39, 2, "generic-match.cc", 8705,
"generic_simplify_127");
-
- <bb 39> [local count: 104528766]:
- # DEBUG BEGIN_STMT
- # DEBUG __t => NULL
- # DEBUG __f => NULL
- # DEBUG __l => NULL
- # DEBUG __g => NULL
_43 = BIT_FIELD_REF <_39->base, 8, 16>;
and you can see constant folding is there and removes the comparison.
I think 26 is INTEGER_CST even.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
[not found] <bug-14840-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2022-11-18 5:02 ` pinskia at gcc dot gnu.org
@ 2022-11-19 17:10 ` cvs-commit at gcc dot gnu.org
2022-11-19 17:11 ` pinskia at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-11-19 17:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:
https://gcc.gnu.org/g:5c021f17e7d09a0eae2d6fb875c9a5484bd4e043
commit r13-4170-g5c021f17e7d09a0eae2d6fb875c9a5484bd4e043
Author: Andrew Pinski <apinski@marvell.com>
Date: Fri Nov 18 05:05:03 2022 +0000
constexprify some tree variables
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.
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* [Bug middle-end/14840] fold tree_code_type[CST] and tree_code_length[CST] in GCC itself
[not found] <bug-14840-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2022-11-19 17:10 ` cvs-commit at gcc dot gnu.org
@ 2022-11-19 17:11 ` pinskia at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-11-19 17:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |13.0
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed finally.
^ permalink raw reply [flat|nested] 9+ messages in thread