https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #29 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:ea0b12523d0d9a9059b5173ce9653b92ddfb284f
commit r10-6698-gea0b12523d0d9a9059b5173ce9653b92ddfb284f
Author: Martin Liska
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #28 from Martin Liška ---
Stats one more time (should not wrap around):
== Stats for /tmp/prev-gcc ==
stats for indirect_call:
Total: 9218, total freq: 5945116271, covered freq: 3610877419 (60.74%)
Histogram:
0 tracked: 6257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #27 from Martin Liška ---
I've just made an experiment with the dynamic allocation of TOPN profile counts
(similarly to what clang does).
There's a GCC branch that does instrumentation and profiling (including
merging):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #26 from Martin Liška ---
(In reply to Jan Hubicka from comment #25)
> I wonder if that is because of parallel updates. There is quite a lot of
> time between prunning and streaming out. If Firefox forks while other
> threads are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #25 from Jan Hubicka ---
I wonder if that is because of parallel updates. There is quite a lot of time
between prunning and streaming out. If Firefox forks while other threads are
running, it will mess up the streamed data quite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #24 from Jan Hubicka ---
You can get gcda files from the treeherder links
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/GacHgozaSRWbybgeUGzHVQ/runs/0/artifacts/public/build/profdata.tar.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #23 from Jan Hubicka ---
This is stat for clang build with current mainline. half of invalidated
counters is pretty high (as expected given large number of runs merged)
== Stats for instrumented-gcc-new/ ==
stats for indirect_call:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #22 from Martin Liška ---
For GCC I see the frequency of only one target aligned:
== Stats for before ==
stats for indirect_call:
total: 9210 freq: 5943636909
not executed at all: 6249
invalid: 669 (7.26%) freq:2219809025
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #21 from Martin Liška ---
(In reply to Jan Hubicka from comment #20)
> And thanks for the gcov-analysis improvemnets. It is quite handy tool now :)
Good to hear.
> and it is interesting to know where the many-target calls are.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #20 from Jan Hubicka ---
And thanks for the gcov-analysis improvemnets. It is quite handy tool now :)
and it is interesting to know where the many-target calls are. Clearly there is
not much to win on walk_tree, but I guess it all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #19 from Jan Hubicka ---
Seems that the multi-target speculation fallout is now fixed and also indirect
call profiling works similarly as to gcc9 now if the reproducibility logic is
disabled.
I re-benchmarked Firefox. Reproducible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #18 from Martin Liška ---
I've got more detailed stats for current GCC master with 4 TOPN counters
(default) and 8 TOPN counters:
$ gcov-dump-analysis.py gcc-4 4
== Stats for gcc-4 ==
stats for indirect_call:
total: 9210 freq:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #17 from Jan Hubicka ---
I further hacked the script to record only values that are useful, where useful
means with greater count then all / TOPN_VALUES / 2. I use same test in GCC
itself (that was bug in original luxou's patch that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #16 from Martin Liška ---
(In reply to Jan Hubicka from comment #15)
> This is frequency scaled by #of executions:
>
> == Stats for /aux/hubicka/firefox2019-trunktest ==
> stats for indirect_call:
> total: 160451
> invalid: 542
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #15 from Jan Hubicka ---
This is frequency scaled by #of executions:
== Stats for /aux/hubicka/firefox2019-trunktest ==
stats for indirect_call:
total: 160451
invalid: 542 (0.34%) freq:276193364 (33.87%)
tracked values:
0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #14 from Jan Hubicka ---
> This seems reasonable well, 542/(21514+3151+866+11) = 2%.
I think one needs to consider only calls that was trained and have at least two
possible targets. With this metric it is more like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #13 from Martin Liška ---
(In reply to Jan Hubicka from comment #12)
> This is stat for Firefox with current mainline.
>
> == Stats for firefox2019-trunktest ==
> stats for indirect_call:
> total: 160451
> invalid: 542
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #12 from Jan Hubicka ---
This is stat for Firefox with current mainline.
== Stats for firefox2019-trunktest ==
stats for indirect_call:
total: 160451
invalid: 542
tracked values:
0 values: 134367 times (83.74%)
1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:e3fe0070c189e214d51cfc314591b6ffa526fb2f
commit r10-6200-ge3fe0070c189e214d51cfc314591b6ffa526fb2f
Author: Jan Hubicka
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #10 from Jan Hubicka ---
-fvpt still has no effect on Firefox
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try=20725e2c319ad69128f075248bc41a0e97029437=try=8a26cb77fed6ccc6752c6ad906a8e20767b454a1=1
while it used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #9 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:7491c17fe01d8cf116f645532d46120029b26408
commit r10-6145-g7491c17fe01d8cf116f645532d46120029b26408
Author: Martin Liska
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #7 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:5f32f9cf13f99f6295591927950aaf98aa8dba91
commit r10-6139-g5f32f9cf13f99f6295591927950aaf98aa8dba91
Author: Martin Liska
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #6 from Martin Liška ---
> Yes, that makes sense. We should do it both during merging and during
> instrumentation. If we choose a drop level equal to 10^2 or 10^3 we should
> not probably introduce a divergence.
Instrumentation is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #5 from Martin Liška ---
>
> So the histogram of destinations is indeed greatly dominated by one
> estination but there are very many others (not all are listed since I
> started dropping them).
>
> One way to make reproducible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #4 from Jan Hubicka ---
Looking into how getter variable is determined:
vp_35 is function parameter
_124 = MEM[(const struct Value *)vp_35(D)].asBits_;
_125 = _124 ^ 18446181123756130304;
_126 = (struct JSObject *) _125
...
_50 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #2 from Jan Hubicka ---
Increasing number of entries does not seem to help:
Indirect call counterall: 140960933, values: [429856732:-1], [484692916:1218],
[1203869319:12593], [245854587:8179], [1829590552:52], [401302964:7072],
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
31 matches
Mail list logo
