From: Jan Hubicka <hubicka@ucw.cz>
To: "Martin Liška" <mliska@suse.cz>
Cc: gcc-patches@gcc.gnu.org, "hubicka >> Jan Hubicka" <hubicka@ucw.cz>
Subject: Re: [PATCH 3/5] IPA ICF pass
Date: Sat, 11 Oct 2014 08:23:00 -0000 [thread overview]
Message-ID: <20141011081944.GD5172@kam.mff.cuni.cz> (raw)
In-Reply-To: <54387267.3030106@suse.cz>
>
> After few days of measurement and tuning, I was able to get numbers to the following shape:
> Execution times (seconds)
> phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 1412 kB ( 0%) ggc
> phase opt and generate : 27.83 (59%) usr 0.66 (19%) sys 28.52 (37%) wall 1028813 kB (24%) ggc
> phase stream in : 16.90 (36%) usr 0.63 (18%) sys 17.60 (23%) wall 3246453 kB (76%) ggc
> phase stream out : 2.76 ( 6%) usr 2.19 (63%) sys 31.34 (40%) wall 2 kB ( 0%) ggc
> callgraph optimization : 0.36 ( 1%) usr 0.00 ( 0%) sys 0.35 ( 0%) wall 40 kB ( 0%) ggc
> ipa dead code removal : 3.31 ( 7%) usr 0.01 ( 0%) sys 3.25 ( 4%) wall 0 kB ( 0%) ggc
> ipa virtual call target : 3.69 ( 8%) usr 0.03 ( 1%) sys 3.80 ( 5%) wall 21 kB ( 0%) ggc
> ipa devirtualization : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.15 ( 0%) wall 13704 kB ( 0%) ggc
> ipa cp : 1.11 ( 2%) usr 0.07 ( 2%) sys 1.17 ( 2%) wall 188558 kB ( 4%) ggc
> ipa inlining heuristics : 8.17 (17%) usr 0.14 ( 4%) sys 8.27 (11%) wall 494738 kB (12%) ggc
> ipa comdats : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall 0 kB ( 0%) ggc
> ipa lto gimple in : 1.86 ( 4%) usr 0.40 (11%) sys 2.20 ( 3%) wall 537970 kB (13%) ggc
> ipa lto gimple out : 0.19 ( 0%) usr 0.08 ( 2%) sys 0.27 ( 0%) wall 2 kB ( 0%) ggc
> ipa lto decl in : 12.20 (26%) usr 0.37 (11%) sys 12.64 (16%) wall 2441687 kB (57%) ggc
> ipa lto decl out : 2.51 ( 5%) usr 0.21 ( 6%) sys 2.71 ( 3%) wall 0 kB ( 0%) ggc
> ipa lto constructors in : 0.13 ( 0%) usr 0.02 ( 1%) sys 0.17 ( 0%) wall 15692 kB ( 0%) ggc
> ipa lto constructors out: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc
> ipa lto cgraph I/O : 0.54 ( 1%) usr 0.09 ( 3%) sys 0.63 ( 1%) wall 407182 kB (10%) ggc
> ipa lto decl merge : 1.34 ( 3%) usr 0.00 ( 0%) sys 1.34 ( 2%) wall 8220 kB ( 0%) ggc
> ipa lto cgraph merge : 1.00 ( 2%) usr 0.00 ( 0%) sys 1.00 ( 1%) wall 14605 kB ( 0%) ggc
> whopr wpa : 0.92 ( 2%) usr 0.00 ( 0%) sys 0.89 ( 1%) wall 1 kB ( 0%) ggc
> whopr wpa I/O : 0.01 ( 0%) usr 1.90 (55%) sys 28.31 (37%) wall 0 kB ( 0%) ggc
> whopr partitioning : 2.81 ( 6%) usr 0.01 ( 0%) sys 2.83 ( 4%) wall 4943 kB ( 0%) ggc
> ipa reference : 1.34 ( 3%) usr 0.00 ( 0%) sys 1.35 ( 2%) wall 0 kB ( 0%) ggc
> ipa profile : 0.20 ( 0%) usr 0.01 ( 0%) sys 0.21 ( 0%) wall 0 kB ( 0%) ggc
> ipa pure const : 1.62 ( 3%) usr 0.00 ( 0%) sys 1.63 ( 2%) wall 0 kB ( 0%) ggc
> ipa icf : 2.65 ( 6%) usr 0.02 ( 1%) sys 2.68 ( 3%) wall 1352 kB ( 0%) ggc
> inline parameters : 0.00 ( 0%) usr 0.01 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc
> tree SSA rewrite : 0.11 ( 0%) usr 0.01 ( 0%) sys 0.08 ( 0%) wall 18919 kB ( 0%) ggc
> tree SSA other : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc
> tree SSA incremental : 0.24 ( 1%) usr 0.01 ( 0%) sys 0.32 ( 0%) wall 11325 kB ( 0%) ggc
> tree operand scan : 0.15 ( 0%) usr 0.02 ( 1%) sys 0.18 ( 0%) wall 116283 kB ( 3%) ggc
> dominance frontiers : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc
> dominance computation : 0.13 ( 0%) usr 0.01 ( 0%) sys 0.16 ( 0%) wall 0 kB ( 0%) ggc
> varconst : 0.01 ( 0%) usr 0.02 ( 1%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc
> loop fini : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc
> unaccounted todo : 0.55 ( 1%) usr 0.00 ( 0%) sys 0.56 ( 1%) wall 0 kB ( 0%) ggc
> TOTAL : 47.49 3.48 77.46 4276682 kB
>
> and I was able to reduce function bodies loaded in WPA to 35% (from previous 55%). The main problem
35% means that 35% of all function bodies are compared with something else? That feels pretty high.
but overall numbers are not so terrible.
> with speed was hidden in work list for congruence classes, where hash_set was used. I chose the data
> structure to support delete operation, but it was really slow. Thus, hash_set was replaced with linked list
> and a flag is used to identify if a set is removed or not.
Interesting, I would not expect bottleneck in a congruence solving :)
>
> I have no clue who complicated can it be to implement release_body function to an operation that
> really releases the memory?
I suppose one can keep the caches from streamer and free trees read. Freeing
gimple statemnts, cfg should be relatively easy.
Lets however first try to tune the implementation rather than try to this hack
implemented. Explicit ggc_free calls traditionally tended to cause some negative
reactions wrt memory fragmentation concerns.
>
> Markus' problem with -fprofile-use has been removed, IPA-ICF is preceding devirtualization pass. I hope it is fine?
Yes, I think devirtualization should actually work better with identical
virutal methods merged. We just need to be sure it sees through the newly
introduced aliases (there should be no thunks for virutal methods)
Honza
next prev parent reply other threads:[~2014-10-11 8:19 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 10:07 [PATCH 1/5] New Identical Code Folding IPA pass mliska
2014-06-16 10:07 ` [PATCH 4/5] Existing tests fix mliska
2014-06-17 19:52 ` Jeff Law
2014-06-17 20:50 ` Rainer Orth
2014-06-18 9:02 ` Martin Liška
2014-06-30 12:12 ` Martin Liška
2014-09-26 12:21 ` Martin Liška
2014-06-16 10:07 ` [PATCH 2/5] Existing call graph infrastructure enhancement mliska
2014-06-17 20:00 ` Jeff Law
2014-06-30 11:49 ` Martin Liška
2014-06-30 18:54 ` Jeff Law
2014-07-17 14:54 ` Martin Liška
2014-08-25 9:56 ` Martin Liška
2014-08-25 16:12 ` Jan Hubicka
2014-08-27 21:12 ` Jeff Law
2014-09-24 14:23 ` Martin Liška
2014-09-24 15:01 ` Jan Hubicka
2014-09-26 10:19 ` Martin Liška
2014-06-16 10:07 ` [PATCH 5/5] New tests introduction mliska
2014-06-17 19:53 ` Jeff Law
2014-06-30 12:14 ` Martin Liška
2014-10-19 8:19 ` Andreas Schwab
2014-10-23 12:34 ` Martin Liška
2014-06-16 10:07 ` [PATCH 3/5] IPA ICF pass mliska
2014-06-20 7:32 ` Trevor Saunders
2014-06-26 11:18 ` Martin Liška
2014-07-05 21:44 ` Gerald Pfeifer
2014-07-05 22:53 ` Jan Hubicka
2014-07-17 15:23 ` Martin Liška
2014-09-26 12:20 ` Martin Liška
2014-09-26 14:44 ` Markus Trippelsdorf
2014-09-26 23:27 ` Jan Hubicka
2014-09-27 5:59 ` Markus Trippelsdorf
2014-09-27 7:47 ` Markus Trippelsdorf
2014-09-27 10:46 ` Martin Liška
2014-09-27 10:37 ` Martin Liška
2014-09-28 2:21 ` Jan Hubicka
2014-10-10 23:54 ` Fakturace
2014-10-11 0:02 ` Martin Liška
2014-10-11 8:23 ` Jan Hubicka [this message]
2014-10-13 13:20 ` Martin Liška
2014-10-13 13:29 ` Jan Hubicka
2014-09-27 10:32 ` Martin Liška
2014-09-26 20:47 ` Jan Hubicka
2014-10-11 0:08 ` Martin Liška
2014-10-11 8:26 ` Jan Hubicka
2014-10-13 15:17 ` Martin Liška
2014-10-14 16:12 ` Jan Hubicka
2014-10-15 17:06 ` Martin Liška
2014-10-22 21:20 ` Jiong Wang
2014-11-06 3:01 ` Joey Ye
2014-11-06 9:03 ` Jan Hubicka
2014-11-13 22:26 ` H.J. Lu
2015-01-20 21:29 ` H.J. Lu
2014-09-26 22:27 ` Jan Hubicka
2014-10-11 0:23 ` Martin Liška
2014-10-11 9:05 ` Jan Hubicka
2014-06-24 20:31 ` Jeff Law
2014-06-26 16:02 ` Martin Liška
2014-06-26 18:46 ` Jan Hubicka
2014-06-30 12:05 ` Martin Liška
2014-07-01 23:45 ` Trevor Saunders
2014-06-30 19:06 ` Jeff Law
2014-06-17 19:49 ` [PATCH 1/5] New Identical Code Folding IPA pass Jeff Law
2014-06-18 19:05 ` Jan Hubicka
2014-06-17 20:09 ` Paolo Carlini
2014-06-18 8:46 ` Martin Liška
2014-06-18 8:49 ` Paolo Carlini
2014-06-17 20:17 ` David Malcolm
2014-06-18 8:10 ` Martin Liška
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141011081944.GD5172@kam.mff.cuni.cz \
--to=hubicka@ucw.cz \
--cc=gcc-patches@gcc.gnu.org \
--cc=mliska@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).