http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #18 from Jakub Jelinek ---
Author: jakub
Date: Fri Mar 28 10:25:34 2014
New Revision: 208893
URL: http://gcc.gnu.org/viewcvs?rev=208893&root=gcc&view=rev
Log:
PR ipa/60315
* g++.dg/torture/pr60315.C: Add -std=c++11 to dg-optio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #17 from rguenther at suse dot de ---
On March 26, 2014 10:58:18 PM CET, hubicka at ucw dot cz
wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
>
>--- Comment #16 from Jan Hubicka ---
>> forwprop would do that, but the enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #16 from Jan Hubicka ---
> forwprop would do that, but the enum is unsigned int while the
> switch value is int and thus simplify_gimple_switch bails out
> because the conversion is not value-preserving.
>
> So the frontend would need
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #15 from rguenther at suse dot de ---
On Wed, 26 Mar 2014, hubicka at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
>
> --- Comment #14 from Jan Hubicka ---
> The compile time hog issue is fixed now. We
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #14 from Jan Hubicka ---
The compile time hog issue is fixed now. We still fix the predicates for
switch statement (to get pass NOP_EXPR) since it seems very common pattern.
Richard: I suppose we can't fold away the NOP_EXPR easily e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #13 from Jan Hubicka ---
Author: hubicka
Date: Wed Mar 26 02:11:57 2014
New Revision: 208831
URL: http://gcc.gnu.org/viewcvs?rev=208831&root=gcc&view=rev
Log:
PR ipa/60315
* cif-code.def (UNREACHABLE) New code.
* ipa-inli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #12 from Jan Hubicka ---
Created attachment 32442
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32442&action=edit
Better patch
I am attaching more complete patch. There is quite bad wrong code bug in
pure-const that updates dec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #11 from Jan Hubicka ---
Created attachment 32439
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32439&action=edit
Patch I am testing
this patch implements the trick of redirecting call edges to UNREACHABLE. It
solves the compil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #10 from Jan Hubicka ---
Actually the problem here seems to be that we soon work out that most of edges
are never executed, yet we still inlining them. The metrics are not growing
then so we take time to hit the limits. I guess with a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #9 from Jan Hubicka -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #7 from Richard Biener ---
Note that we seem to fail to update BB predicates for switch stmts.
size:0.00, time:0.00, predicate:(true)
size:3.00, time:2.00, predicate:(not inlined)
size:2.00, time:2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #6 from Richard Biener ---
Btw, the smaller testcase (E4 case commented) shows exactly the same behavior,
we just seem to be exponential so only adding E4 makes it "really" bad.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #5 from Richard Biener ---
Hmm, ok - it is supposed to only account for the extra call edges in the
inlined
bodies. The actual issue seems to be
Deciding on inlining of small functions. Starting with size 114.
Enqueueing calls in Te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #4 from Richard Biener ---
When calling do_estimate_edge_size to compute the effect on caller size when
inlining an edge we call estimate_node_size_and_time which eventually recurses
down to estimate_calls_size_and_time (why!? call ed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #3 from Richard Biener ---
This whole thing updating keys and such should use a proper lattice of
per-cgraph and per-edge node sizes/times which can be updated with a
less ad-hoc algorithm than the current one which easily and complete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
Richard Biener changed:
What|Removed |Added
Blocks||60243
--- Comment #2 from Richard Biener
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
Richard Biener changed:
What|Removed |Added
Keywords||compile-time-hog
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
20 matches
Mail list logo