https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #29 from Richard Biener rguenth at gcc dot gnu.org ---
Sth like
@@ -672,8 +650,18 @@ cleanup_tree_cfg_bb (basic_block bb)
if (single_succ_p (bb)
can_merge_blocks_p (bb, single_succ (bb)))
{
- merge_blocks (bb,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #23 from Richard Biener rguenth at gcc dot gnu.org ---
Funnily apart from the IPA inline summary updating issue the next important
time-hog is basic-block splitting we do for inlining a call. This is because
split_block moves the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #22 from Richard Biener rguenth at gcc dot gnu.org ---
I wonder why we have split_bb_on_noreturn_calls in cfg-cleanup rather than in
fixup_cfg. It's quite expensive, walking all stmts and calling
gimple_call_noreturn_p which is very
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #24 from Richard Biener rguenth at gcc dot gnu.org ---
So in gimple_expand_calls_inline we could look only at BBs last stmt for the
actual inlining but for the rest just do the basic-block splitting. And then
perform that walk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #26 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Tue Mar 10 12:44:01 2015
New Revision: 221321
URL: https://gcc.gnu.org/viewcvs?rev=221321root=gccview=rev
Log:
2015-03-09 Richard Biener rguent...@suse.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #27 from rguenther at suse dot de rguenther at suse dot de ---
On Tue, 10 Mar 2015, jakub at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
Jakub Jelinek jakub at gcc dot gnu.org changed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #28 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #27)
On Tue, 10 Mar 2015, jakub at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #21 from rguenther at suse dot de rguenther at suse dot de ---
On Tue, 10 Mar 2015, hubicka at ucw dot cz wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #19 from Jan Hubicka hubicka at ucw dot cz ---
Hmm,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #20 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Tue Mar 10 08:25:31 2015
New Revision: 221308
URL: https://gcc.gnu.org/viewcvs?rev=221308root=gccview=rev
Log:
2015-03-10 Richard Biener rguent...@suse.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #16 from Richard Biener rguenth at gcc dot gnu.org ---
callgrind shows the cgraph_edge_hasher quite high in the profile (via
redirect_all_calls). I suppose as the large main is a single BB walking
all stmts over-and-over is quite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #18 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #17)
(In reply to Richard Biener from comment #16)
callgrind shows the cgraph_edge_hasher quite high in the profile (via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #17 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #16)
callgrind shows the cgraph_edge_hasher quite high in the profile (via
redirect_all_calls). I suppose as the large main is a single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #19 from Jan Hubicka hubicka at ucw dot cz ---
Hmm, it is definitely wasteful to call the call stmt redirection so many times
- it only needs
to be called once per statement. We probably could call it only on newly
introduced BBs, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #14 from Jan Hubicka hubicka at gcc dot gnu.org ---
Yeah, this is the old problem that after each inline we recompute the size of
the whole function inlined into. This means walking the whole inline tree and
sum size of all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #13 from Richard Biener rguenth at gcc dot gnu.org ---
GCC 5 needs 31s and a peak of 2GB at -O0:
integrated RA : 5.91 (19%) usr 0.69 (11%) sys 6.41 (17%) wall
1615872 kB (55%) ggc
LRA non-specific: 2.41 (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-17
00:08:07 UTC ---
Author: hubicka
Date: Fri Dec 17 00:08:02 2010
New Revision: 167964
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167964
Log:
PR middle-end/44563
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-13
13:22:28 UTC ---
Patched compiler at -O2 now shows:
integration : 166.20 (16%) usr 0.19 ( 1%) sys 166.86 (15%) wall
92691 kB ( 4%) ggc
tree CCP :
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-12
23:55:24 UTC ---
With -O2 during early optimization we get to 68% in cgraph_check_inline_limits.
This is weird since early inliner should not be terribly sensitive to this. I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||dnovillo at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-13
00:59:53 UTC ---
... actually split_bb does not use gsi_for_stmt since it has to walk all the
statements in the BB anyway. It seems that it is one of routines updating
callers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-13
01:07:33 UTC ---
My profile was at -O2. Concerning Jakub's callgrind, the -O0 compilation
finishes in about 44s for me. Profile is:
4349 3.8607 libc-2.11.1.so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||vmakarov at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-13
01:46:39 UTC ---
Created attachment 22730
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22730
Fix for inline cost problem
The attached patch fixes the inliner cost
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-17 10:36 ---
The issue is not so much the number of functions but the number of calls
in main (and thus its size).
With GCC 4.3.4 I see
parser: 6.87 (12%) usr 0.79 (14%) sys 8.14 (13%) wall
266316 kB
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-17 10:44 ---
Growth in time and memory is linear in the number of functions for me (GCC
4.5).
rguent...@murzim:/tmp ~/bin/maxmem2.sh /usr/bin/time gcc-4.5 -S gcc_16kgen1.c
-o /dev/null
14.60user 0.61system 0:15.42elapsed 98%CPU
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-17 12:28 ---
Created an attachment (id=20932)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20932action=view)
callgrind.out.bz2
Seems it is mainly df and RA that eats the time for -O0 -g0.
--
--- Comment #1 from jvoss at altsci dot com 2010-06-17 04:14 ---
Created an attachment (id=20931)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20931action=view)
A c file that generates a c file that is the test case.
gcc -o gcc_64kgen1 gcc_64kgen1.c -Wall
./gcc_64kgen1
29 matches
Mail list logo
