https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70586
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Martin has collected predictor hitrates with current mainline. It seems that
some of predictors no longer works very well. In particular:
loop iv compare, continue, const return, fail
: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
$ cat a.C
struct s
{
int a;
s() {a=1;}
~s() {}
};
int t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70929
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71015
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Jan Hubicka
||2016-05-13
CC||hubicka at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jan Hubicka ---
mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70018
Jan Hubicka changed:
What|Removed |Added
Summary|[4.9/5/6/7 Regression] |[4.9/5/6 Regression]
|Po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71159
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146
--- Comment #9 from Jan Hubicka ---
Aha,
this is because we do not re-evaulate the predicates for inlined edges and in
the inline order we first inline into thunk and then inline thunk. This results
in some extra work done by tree-inline but is h
||2016-05-20
CC||hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #5 from Jan Hubicka ---
I will take a look.
||2016-05-20
CC||hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #6 from Jan Hubicka ---
I will take a look. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67992
--- Comment #7 from Jan Hubicka ---
Joshua: gcov is seriously old tool. There is quite some need to handle profile
in more generic matter (for autoFDO/LTO and other cases). So if you have more
flexible implementation, it would make sense to repla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67937
--- Comment #6 from Jan Hubicka ---
We can have negative counters on fake edges in case the code uses abnormal
edges that we can't instrument correctly. setjmp/longjmp is one of examples.
If you profile kernel, you will have inconsistencies in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71335
Jan Hubicka changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69271
--- Comment #8 from Jan Hubicka ---
Ok, compiling:
int bar = 0;
extern int bar_alias __attribute__((weak, alias("bar")));
main()
{
printf ("%i %i\n",bar,bar_alias);
}
as a static library leads to no dynamic relocations, but compiling as shared
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #3 from Jan Hubicka ---
I will take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66295
--- Comment #4 from Jan Hubicka ---
In resolution file we have:
1
q.o 5
200 7c41b073ca657863 PREVAILING_DEF_IRONLY _Z3foov
212 7c41b073ca657863 PREVAILING_DEF_IRONLY _Z3foov.arch_core2
215 7c41b073ca657863 PREVAILING_DEF_IRONLY _Z3foov.resolver
2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466
--- Comment #10 from Jan Hubicka ---
Iterations bounds are computed at early optimization time and maintained
thorough. So the info is computed at thread2 time.
Looking into testcase I noticed that jump threading seems to be doing useless
work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71403
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71403
Jan Hubicka changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #10 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81462
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81462
--- Comment #3 from Jan Hubicka ---
Author: hubicka
Date: Tue Jul 18 13:49:30 2017
New Revision: 250310
URL: https://gcc.gnu.org/viewcvs?rev=250310&root=gcc&view=rev
Log:
PR middle-end/81462
* predict.c (set_even_probabilities):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81463
--- Comment #1 from Jan Hubicka ---
Author: hubicka
Date: Tue Jul 18 13:51:22 2017
New Revision: 250311
URL: https://gcc.gnu.org/viewcvs?rev=250311&root=gcc&view=rev
Log:
PR middle-end/81463
* cfgloopmanip.c (scale_loop_profile)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
--- Comment #12 from Jan Hubicka ---
Author: hubicka
Date: Wed Jul 19 18:08:07 2017
New Revision: 250358
URL: https://gcc.gnu.org/viewcvs?rev=250358&root=gcc&view=rev
Log:
PR middle-end/81331
* except.c (maybe_add_nop_after_sect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
--- Comment #13 from Jan Hubicka ---
Author: hubicka
Date: Wed Jul 19 21:06:55 2017
New Revision: 250370
URL: https://gcc.gnu.org/viewcvs?rev=250370&root=gcc&view=rev
Log:
PR middle-end/81331
* except.c (execute): Fix ordering is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
Jan Hubicka changed:
What|Removed |Added
Summary|[8 Regression] FAIL:|[5/6/7 Regression] missed
||hubicka at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Jan Hubicka ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81030
--- Comment #10 from Jan Hubicka ---
Author: hubicka
Date: Thu Jul 20 11:27:31 2017
New Revision: 250383
URL: https://gcc.gnu.org/viewcvs?rev=250383&root=gcc&view=rev
Log:
PR middle-end/81030
* cfgbuild.c (find_many_sub_basic_bl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81462
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81290
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80197
--- Comment #9 from Jan Hubicka ---
The original idea of tracing was that we can pro-actively duplicate tails and
rely on crossjumping to merge the paths back if they did not trigger context
sensitive optimizations. Nowdays crossjumping much wea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81307
Jan Hubicka changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2 f
||hubicka at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Jan Hubicka ---
This is bug in stabs output - I am not sure if we can support debug info for
split functions there somehow. Added some info to PR81307
*** This bug has been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81614
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81614
--- Comment #7 from Jan Hubicka ---
As a historical note, X86_TUNE_PARTIAL_REG_STALL was moved to historical relics
at the time both current designs (Penium 4 and Athlon) were using
PARTIAL_REG_DEPENDENCY. I believed that main reason for this des
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81465
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81318
--- Comment #23 from Jan Hubicka ---
determine_unlikely_bbs is intended to propagate known to be cold bbs
(profile_count::zero) rather than guessed_zero so it seems to do the job
correctly here, because we decide to trust the cold attribute (I am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81133
--- Comment #8 from Jan Hubicka ---
I see. compute_uninlined_call_time uses counts when they are available and
frequencies when they are not. It makes sense that dropping count to 0 will
lead to change of compute_uninlined_call_time. I am bit su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81702
Jan Hubicka changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #4 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80435
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224
--- Comment #14 from Jan Hubicka ---
Author: hubicka
Date: Sun Apr 30 15:02:11 2017
New Revision: 247417
URL: https://gcc.gnu.org/viewcvs?rev=247417&root=gcc&view=rev
Log:
PR ipa/79224
* ipa-inline-analysis.c (dump_predicate): A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80581
--- Comment #4 from Jan Hubicka ---
This is an roundoff issue. While summing the times it happens that n*1000/1000
> n. The following patch should silence it unless they cummulate for very
large value (which I will likely want to investigate th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80609
--- Comment #3 from Jan Hubicka ---
Author: hubicka
Date: Wed May 3 16:14:32 2017
New Revision: 247555
URL: https://gcc.gnu.org/viewcvs?rev=247555&root=gcc&view=rev
Log:
PR bootstrap/80609
* ipa-inline.h (inline_summary): Add c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80581
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80743
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #9 from Jan Hubicka ---
will take a look at the cgraph issue
||hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #1 from Jan Hubicka ---
Mine.
||2017-06-05
CC||hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jan Hubicka ---
I will take a look. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80978
--- Comment #4 from Jan Hubicka ---
Author: hubicka
Date: Tue Jun 6 11:30:54 2017
New Revision: 248915
URL: https://gcc.gnu.org/viewcvs?rev=248915&root=gcc&view=rev
Log:
PR bootstrap/80978
* tree-cfg.c (execute_fixup_cfg): Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866
--- Comment #11 from Jan Hubicka ---
Author: hubicka
Date: Thu Jun 15 18:42:10 2017
New Revision: 249224
URL: https://gcc.gnu.org/viewcvs?rev=249224&root=gcc&view=rev
Log:
PR lto/69866
* lto-symtab.c (lto_symtab_merge_symbols):
||hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #2 from Jan Hubicka ---
I will take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81261
--- Comment #2 from Jan Hubicka ---
Author: hubicka
Date: Fri Jun 30 21:09:13 2017
New Revision: 249856
URL: https://gcc.gnu.org/viewcvs?rev=249856&root=gcc&view=rev
Log:
PR ipa/81261
* tree-inline.c (expand_call_inline): Combin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033
--- Comment #8 from Jan Hubicka ---
We discussed this on IRC some time ago. The problem is that bb partitioning
seems broken on Darwin. Until the mentioned revision only -fprofile-use enabled
it and thus the bug probably went unnoticed because no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81285
--- Comment #8 from Jan Hubicka ---
Author: hubicka
Date: Mon Jul 3 12:17:59 2017
New Revision: 249904
URL: https://gcc.gnu.org/viewcvs?rev=249904&root=gcc&view=rev
Log:
PR bootstrap/81285
* loop-doloop.c (add_test): Update pro
||hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #2 from Jan Hubicka ---
this is bug in threadupdate which makes count to be reliably zero while it is
just result of misupdate and another bug in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81290
--- Comment #3 from Jan Hubicka ---
Author: hubicka
Date: Mon Jul 3 14:40:46 2017
New Revision: 249924
URL: https://gcc.gnu.org/viewcvs?rev=249924&root=gcc&view=rev
Log:
PR middle-end/81290
* predict.c (force_edge_cold): Be mor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81290
--- Comment #5 from Jan Hubicka ---
Can you just write me instructions how to reproduce it? What is the
configuration triplet? I tried target=powerpc-linux-gnuspe which seems to work
fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81290
--- Comment #7 from Jan Hubicka ---
Hmm, I configured with:
../configure --host=x86_64-pc-linux-gnu --target=powerpc-e500v2-linux-gnuspe
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/powerpc-e500v2-linux-gnuspe/gcc-b
||2017-07-05
CC||hubicka at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Jan Hubicka ---
The same slowdown is seen when compiling combine.ii, too, so it is not caused
by tramp3d not being representative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80838
--- Comment #5 from Jan Hubicka ---
OK, found the problem. LTO binary is built with -fPIC because of the way we
merge options. I saw the same problem previously on Firefox. It is easy
mistake to do. I think we should
1) warn in this case
2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81307
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
--- Comment #2 from Jan Hubicka ---
The wrong code is triggered by partitioning. The function is somewhat odd by
requiring an EH edge to finish properly while we predict EH edges are unlikely.
This is however partly undone by the hack in bb-reor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
--- Comment #3 from Jan Hubicka ---
Created attachment 41702
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41702&action=edit
Working assembly (without profile sanitization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
--- Comment #4 from Jan Hubicka ---
Created attachment 41703
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41703&action=edit
broken assembly (generated by revision 250073)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
--- Comment #5 from Jan Hubicka ---
Created attachment 41704
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41704&action=edit
Assembly with hacked BB movement (so it passes and is closer to bad.s)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
--- Comment #6 from Jan Hubicka ---
Created attachment 41705
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41705&action=edit
bbpart dump (bad version)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
--- Comment #7 from Jan Hubicka ---
Created attachment 41706
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41706&action=edit
bbpart dump (good version)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
Jan Hubicka changed:
What|Removed |Added
CC||ian at airs dot com,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80838
--- Comment #7 from Jan Hubicka ---
Author: hubicka
Date: Mon Jul 10 13:25:23 2017
New Revision: 250094
URL: https://gcc.gnu.org/viewcvs?rev=250094&root=gcc&view=rev
Log:
PR lto/80838
* lto-wrapper.c (remove_option): New functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033
--- Comment #24 from Jan Hubicka ---
I think the patch still need to be updated to correctly handle the symbols
whose names are parethetised which was mentioned on the IRC (weird thing that
seems to be used in objC++ API). That should fix good p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81312
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
--- Comment #9 from Jan Hubicka ---
OK, found it. The problem is in EH table entries like:
.uleb128 .LEHB8-.LCOLDB1
.uleb128 .LEHE8-.LEHB8
.uleb128 .L16-.LCOLDB1
.uleb128 0x1
Now the third entry is landing pad.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81331
--- Comment #11 from Jan Hubicka ---
Created attachment 41766
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41766&action=edit
Patch I am testing
Hi,
this patch adds sanity check that turns the nasty wrong code issue into ICE and
a hack to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70029
--- Comment #11 from Jan Hubicka ---
Given that we are in stage 3 again, I propose to postpone this one for GCC 8. I
will try to get to that early next stage1, so it does not slip again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65654
--- Comment #9 from Jan Hubicka ---
Here I also propose postpone again for GCC 8. I will try to give it priority
next stage1 :(
||2016-12-01
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jan Hubicka ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #6 from Jan Hubicka ---
mine.
||hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #4 from Jan Hubicka ---
Wilco,
do you have a specific function where this happens?
Martin,
do you know what is hitrate of call predictor here? I am not sure
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #9 from Jan Hubicka ---
Let me see if I can reproduce this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77674
--- Comment #7 from Jan Hubicka ---
I am testing the following:
Index: symtab.c
===
--- symtab.c(revision 243291)
+++ symtab.c(working copy)
@@ -2214,6 +2214,8 @@ symtab_node
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #11 from Jan Hubicka ---
I will take a look. I think we should try to fix the profile updating after
jump threading again and see if we need any hacks after that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #14 from Jan Hubicka ---
Author: hubicka
Date: Sun Jan 1 15:40:29 2017
New Revision: 243995
URL: https://gcc.gnu.org/viewcvs?rev=243995&root=gcc&view=rev
Log:
PR middle-end/77484
* predict.def (PRED_CALL): Update hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77674
--- Comment #8 from Jan Hubicka ---
Author: hubicka
Date: Sun Jan 1 23:31:53 2017
New Revision: 243997
URL: https://gcc.gnu.org/viewcvs?rev=243997&root=gcc&view=rev
Log:
PR middle-end/77674
* symtab.c (symtab_node::binds_to_cur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77674
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #21 from Jan Hubicka ---
Author: hubicka
Date: Fri Jan 6 16:10:09 2017
New Revision: 244167
URL: https://gcc.gnu.org/viewcvs?rev=244167&root=gcc&view=rev
Log:
PR middle-end/77484
* predict.def (PRED_POLYMORPHIC_CALL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #24 from Jan Hubicka ---
Author: hubicka
Date: Sun Jan 8 09:53:06 2017
New Revision: 244207
URL: https://gcc.gnu.org/viewcvs?rev=244207&root=gcc&view=rev
Log:
PR middle-end/77484
* predict.def (PRED_INDIR_CALL): Set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #25 from Jan Hubicka ---
Author: hubicka
Date: Tue Jan 10 09:14:54 2017
New Revision: 244260
URL: https://gcc.gnu.org/viewcvs?rev=244260&root=gcc&view=rev
Log:
PR middle-end/77484
* predict.def (PRED_CALL): Set to 67.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78407
--- Comment #2 from Jan Hubicka ---
The following patch fixes the issue
===
--- symtab.c(revision 244386)
+++ symtab.c(working copy)
@@ -1989,13 +1989,12 @@ symtab_node::equa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #26 from Jan Hubicka ---
Hello, did the Gap scores on arm too? Both Itanium and PPC testers seems to
show improved gap scores, so hope arm and the other ppc tester too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #12 from Jan Hubicka ---
Created attachment 40526
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40526&action=edit
Patch I am testing
The profile is quite inconsistent since thread1.
The problem is that duplicate_thread_path do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #13 from Jan Hubicka ---
Author: hubicka
Date: Tue Jan 17 12:49:41 2017
New Revision: 244528
URL: https://gcc.gnu.org/viewcvs?rev=244528&root=gcc&view=rev
Log:
PR middle-end/77445
* tree-ssa-threadupdate.c (remove_ct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #14 from Jan Hubicka ---
With the patch we only give up on some threading in thread4:
q.c.181t.thread4:FSM jump-thread path not considered: duplication of 5 insns is
needed and optimizing for size.
q.c.181t.thread4:FSM jump-thread pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #15 from Jan Hubicka ---
Note that the remaining missed threads loop exit condition test state !=
INVALID which after sequence of threads gets to probability 0 because original
guess from profile_estimate is not realistic.
I guess su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79126
--- Comment #1 from Jan Hubicka ---
I guess we can either add the interval or drop the assert. I basically
included it to make it clear in future that if the number of threads changes,
very likely it will also affect the number of profile mismat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78407
--- Comment #3 from Jan Hubicka ---
Author: hubicka
Date: Thu Jan 19 10:00:56 2017
New Revision: 244612
URL: https://gcc.gnu.org/viewcvs?rev=244612&root=gcc&view=rev
Log:
PR lto/78407
* symtab.c (symtab_node::equal_address_to): F
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #9 from Jan Hubicka ---
I guess it should no longer be waiting then. I will try to take a look.
1301 - 1400 of 3603 matches
Mail list logo
