https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #29 from Robin Dapp ---
Yes, that also appears to work here. There was no lto involved this time?
Now we need to figure out what's different with SPEC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #28 from Filip Kastl ---
Created attachment 57710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57710&action=edit
gcda data for himeno
I've tried sharing non-SPEC gcda data between machines. I used this benchmark
https://ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #27 from Robin Dapp ---
Can you try it with a simpler (non SPEC) test? Maybe there is still something
weird happening with SPEC's scripting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #26 from Filip Kastl ---
Yes, the "before" is r14-5075-gc05f748218a0d5.
I just tried to take the gcda data and use them to compile mcf on another
machine. I also ran into
output.c:87:1: error: corrupted profile info: number o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #25 from Jeffrey A. Law ---
Well, at least in theory SPEC isn't supposed to be changing the sources or
validation criteria on us. So while our copy may be old, I would expect it's
still the same as Filip's.
That doesn't resolve any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #24 from Robin Dapp ---
I rebuilt GCC from scratch with your options but still have the same problem.
Could our sources differ? My SPEC version might not be the most recent but I'm
not aware that mcf changed at some point.
Just to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #23 from Filip Kastl ---
Yeah I also don't know what else to do to make the gcda files work for you :-/
I can send you my compiler binaries but you should have exactly the same if you
compile from the same commit (if I'm not mistake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #22 from Robin Dapp ---
Still the same problem unfortunately.
I'm a bit out of ideas - maybe your compiler executables could help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #21 from Filip Kastl ---
Created attachment 57703
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57703&action=edit
gcda data for the commit before robin's commit (v2)
Here are the gcda files generated with -march=znver4 -mtune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #20 from Robin Dapp ---
No change with -std=gnu99 unfortunately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #19 from Filip Kastl ---
There's indeed another difference. In my case, gcc gets called with -std=gnu99.
Otherwise, I think the options are the same.
gcc -std=gnu99 -c -o pbeampp.o -DSPEC_CPU -DNDEBUG -DWANT_STDC_PROTO
-fprofile-u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #18 from Robin Dapp ---
Hmm, doesn't help unfortunately. A full command line for me looks like:
x86_64-pc-linux-gnu-gcc -c -o pbeampp.o -DSPEC_CPU -DNDEBUG -DWANT_STDC_PROTO
-Ofast -march=znver4 -mtune=znver4 -flto=32 -g -fprofil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #17 from Filip Kastl ---
I have this in the SPEC .cfg file:
OPTIMIZE = -Ofast -g -march=native -mtune=native -flto=32
So the only difference I see is the inclusion of -g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #16 from Robin Dapp ---
Thank you!
I'm having a problem with the data, though.
Compiling with -Ofast -march=znver4 -mtune=znver4 -flto -fprofile-use=/tmp.
Would you mind showing your exact final options for compilation of e.g.
pbeam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
Filip Kastl changed:
What|Removed |Added
Attachment #57699|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
Filip Kastl changed:
What|Removed |Added
Attachment #57698|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #13 from Filip Kastl ---
Hmm. It will be better to have the gcda data for the Robin's commit and the
commit before it. I'll go generate those.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #12 from Filip Kastl ---
Created attachment 57699
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57699&action=edit
gcda data for the commit g:4ea36076d66eea0f - before the change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #11 from Filip Kastl ---
Created attachment 57698
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57698&action=edit
gcda data for the commit g:c3847ca0571e5ace - after the change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #10 from Robin Dapp ---
(In reply to Sam James from comment #9)
> (In reply to Filip Kastl from comment #8)
> > I'd like to help but I'm afraid I cannot send you the SPEC binaries with PGO
> > applied since SPEC is licensed nor can I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #9 from Sam James ---
(In reply to Filip Kastl from comment #8)
> I'd like to help but I'm afraid I cannot send you the SPEC binaries with PGO
> applied since SPEC is licensed nor can I give you access to a Zen4 computer.
> I suppose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #8 from Filip Kastl ---
(In reply to Robin Dapp from comment #7)
> I built executables with and without the commit (-Ofast -march=znver4
> -flto). There is no difference so it must really be something that happens
> with PGO.
> I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #7 from Robin Dapp ---
I built executables with and without the commit (-Ofast -march=znver4 -flto).
There is no difference so it must really be something that happens with PGO.
I'd really need access to a zen4 box or the pgo execut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #6 from Robin Dapp ---
Honestly, I don't know how to analyze/debug this without a zen4, in particular
as it only seems to happen with PGO. I tried locally but of course the
execution time doesn't change (same as with zen3 according
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #5 from Filip Kastl ---
(In reply to Robin Dapp from comment #4)
> Judging by the graph it looks like it was slow before, then got faster and
> now slower again. Is there some more info on why it got faster in the first
> place? Di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #4 from Robin Dapp ---
Judging by the graph it looks like it was slow before, then got faster and now
slower again. Is there some more info on why it got faster in the first place?
Did the patch reverse something or is it rather a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
--- Comment #3 from Filip Kastl ---
Btw, the slowdown seems specific to PGO+LTO, with PGO or LTO by itself the
benchmarks execution times are relatively stable:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=991.60.0&plot.1=992.60.0&pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548
Filip Kastl changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
30 matches
Mail list logo
