https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #39 from Jan Hubicka ---
> Finally, the total between after the last and before the first patch.
> Overall,
> some tests gain some performance and others lose some. The total number of
> instructions has grown somewhat (especially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #38 from Dominik Vogt ---
Finally, the total between after the last and before the first patch. Overall,
some tests gain some performance and others lose some. The total number of
instructions has grown somewhat (especially tonto, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #37 from Dominik Vogt ---
r244260 vs. r244256 (comment 25)
---
run-old.resultrun-new.result
f410.bwaves 1.27s1.27s ( 0.00%, 0.00% )
f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #36 from Dominik Vogt ---
r244207 vs. r244206 (comment 24)
---
run-old.resultrun-new.result
f410.bwaves 1.27s1.27s ( 0.00%, 0.00% )
f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #35 from Dominik Vogt ---
r244167 vs. r244166 (comment 21)
---
run-old.resultrun-new.result
f410.bwaves 1.27s1.27s ( 0.00%, 0.00% )
f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #34 from Dominik Vogt ---
Some Spec2006 results on s390x (zEC12) for the files:
r243995 vs. r243994 (comment 14)
---
run-old.resultrun-new.result
f410.bwaves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #33 from wilco at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #32)
> Apparently fixed. The coremark is PR77445
Yes, my SPEC2006 results look good, no real change. Coremark is now up by 20%
or more, thanks for that :-)
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=77484
--- Comment #31 from Wilco ---
(In reply to Jan Hubicka from comment #30)
> >
> > When I looked at gap at the time, the main change was the reordering of a
> > few
> > if statements in several hot functions. Incorrect block frequencies also
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #30 from Jan Hubicka ---
>
> When I looked at gap at the time, the main change was the reordering of a few
> if statements in several hot functions. Incorrect block frequencies also
> change
> register allocation in a bad way, but I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #29 from Wilco ---
(In reply to Jan Hubicka from comment #28)
> > On SPEC2000 the latest changes look good, compared to the old predictor gap
> > improved by 10% and INT/FP by 0.8%/0.6%. I'll run SPEC2006 tonight.
>
> It is rather su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #28 from Jan Hubicka ---
> On SPEC2000 the latest changes look good, compared to the old predictor gap
> improved by 10% and INT/FP by 0.8%/0.6%. I'll run SPEC2006 tonight.
It is rather surprising you are seeing such large changes fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #27 from wilco at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #26)
> 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.
On SP
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=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=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 #23 from Markus Trippelsdorf ---
Unfortunately vmakarov SPEC tester is currently stalled for most archs.
However it still works for POWER7 and here r244167 shows no effect.
https://vmakarov.fedorapeople.org/spec/spec2000.ibm-p730-05-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #22 from Dominik Vogt ---
> Is changing one a day enough for periodic testers to catch up?
I'll try to keep up with testing.
> New Revision: 244167
Which numbers do you need r244167 vs. r244166 or vs. 243994 or both? (If I'm
suppo
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 #20 from Jan Hubicka ---
Hi,
it turns out that Martin added another column to his statistics script which I
have misinterpretted.
https://gcc.opensuse.org/SPEC/CINT/sb-terbium-head-64/recent.html also shows
interesting reaction
to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #19 from wilco at gcc dot gnu.org ---
> The commit in comment 14 has instroduced size and runtime regressions in the
> Spec2006 testsuite on s390x:
I get reproducible regressions on AArch64 as well with the latest patch
(changes >0.5%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #18 from Dominik Vogt ---
(The perlbench result looks like a bad measurement result; we sometimes have
this on devel machine for unknown reasons, possibly when someone compiles or
tests on a different partition.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #17 from Dominik Vogt ---
Can you make sense of these results? The size of gamess has not changed, but
the runtime has but still looks noticeably worse. The astar performance looks
similar to yesterday's result without the change fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #16 from Jan Hubicka ---
>run-old.resultrun-new.result
> f416.gamess 6.55s6.70s ( 2.29%, -2.24% )
> i400.perlbench 7.17s7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
Dominik Vogt changed:
What|Removed |Added
CC||vogt at linux dot vnet.ibm.com
--- Commen
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=77484
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|6.3 |6.4
--- Comment #13 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #12 from wilco at gcc dot gnu.org ---
(In reply to wilco from comment #10)
> (In reply to Jan Hubicka from comment #9)
> > Created attachment 40217 [details]
> > predict
> >
> > Hi,
> > here is patch adding the polymorphic case, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #11 from Martin Liška ---
I'm planning to run SPEC benchmarks late this week to find a proper value for
the new predictor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #10 from wilco at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #9)
> Created attachment 40217 [details]
> predict
>
> Hi,
> here is patch adding the polymorphic case, too.
>
> Honza
Looks good - gap still improves by 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #9 from Jan Hubicka ---
Hi,
here is patch adding the polymorphic case, too.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #8 from Jan Hubicka ---
> Yes that's it, a single run shows 12% speedup with this patch!
Looks promising. We probably should try to differentiate from polymorphic
calls
as virtual methods are also used in different patterns.
let m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #7 from wilco at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #6)
> Created attachment 40216 [details]
> predict
>
> Aha, indirect calls should probably be treated separately as their use cases
> are quite
> special. What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #6 from Jan Hubicka ---
Aha, indirect calls should probably be treated separately as their use cases
are quite
special. What about this patch? (Maritn, it would be great if you can run the
analyze_brprob
for it)
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
wilco at gcc dot gnu.org changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|-
39 matches
Mail list logo
