Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: thanm at google dot com
Target Milestone: ---
Created attachment 44295
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44295&action=edit
tar file with reproducer sources and makefile
The runtime
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: thanm at google dot com
Target Milestone: ---
Created attachment 46276
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46276&action=edit
Go testcase
The a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #7 from Than McIntosh ---
I patched in your change and reran the original testacse. Verified that this
fixes the problem, compile time now down to ~8 seconds. Thank you for the very
quick turnaround-- much appreciated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #10 from Than McIntosh ---
Update: it looks like we are not out of the woods quite yet -- I am seeing some
similar behavior farther into the build. I will try to produce another reduced
test case (this one is proving more difficult re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #12 from Than McIntosh ---
Created attachment 46304
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46304&action=edit
modified test case (file 2 of 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #11 from Than McIntosh ---
Created attachment 46303
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46303&action=edit
modified test case (file 1 of 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #13 from Than McIntosh ---
I've made a stab at revising the test case to try to trigger the long compile
time that I'm still seeing the real application code. Still not quite there
yet (revised testcase takes maybe a minute to compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #18 from Than McIntosh ---
I tested the most recent commit (270944). That cuts the compile time on the
larger example in half, but still at around 1200 seconds. I took another
profile (will attach an SVG image from 'pprof web').
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #19 from Than McIntosh ---
Created attachment 46313
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46313&action=edit
SVG graph from profiling run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #22 from Than McIntosh ---
Apologies for the delayed response (busy with other bugs yesterday).
Testcase: hard to share the original... it has hundreds if not
thousands of imported packages (it's an auto-generated Go file), and
I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #23 from Than McIntosh ---
Created attachment 46326
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46326&action=edit
dump from -fdump-statistics-stats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #24 from Than McIntosh ---
Did another run with the patch from comment 21. For the offending routine I
get:
phi-translate cache statistics: size 2097143, 1171808 elements, 0.465610
collisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #29 from Than McIntosh ---
Tested patch at https://gcc.gnu.org/bugzilla/attachment.cgi?id=46337 and that
brings compile time now down to about 700 seconds. -ftime-report shows that
tree-PRE is still the major culprit.
Also tested se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #32 from Than McIntosh ---
Compile time for the larger example looks good for the most recent commit on
trunk (271124), ~130 seconds. Thanks for all your help on this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #34 from Than McIntosh ---
GCC 8 and 9 branches -- I'll do that experiment later this morning. It's worth
noting that if the code in questing uses more modern Go constructs (things
introduced in Go 1.11/1.12) it may not compile proper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #35 from Than McIntosh ---
I applied r271124 to the gcc-9 branch and re-ran the large testcase -- still
has the long compile time (2127 seconds), FWIW.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #37 from Than McIntosh ---
(In reply to rguent...@suse.de from comment #36)
> Thanks for the experiment. I guess I will limit backporting things
> to the GCC 9 branch then. Am I correct that the 2127 seconds are
> the same regardle
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: thanm at google dot com
CC: cmang at google dot com
Target Milestone: ---
Compiling the attached test case with gccgo results in an ICE. Example:
$ go build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80226
--- Comment #1 from Than McIntosh ---
This seems to do the trick:
diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc
index ed6fc2c6105..62baa91fab8 100644
--- a/gcc/go/go-gcc.cc
+++ b/gcc/go/go-gcc.cc
@@ -2081,7 +2081,8 @@ Gcc_backend::return_sta
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: thanm at google dot com
Target Milestone: ---
Created attachment 36392
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36392&action=edit
reduced test case (C++)
Compiling the attached example with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67718
--- Comment #2 from Than McIntosh ---
>>using __builtin_copysignl should generate better code generation anyways.
Tried replacing the guts of the function with a call to __builtin_copysignl --
the bug is still present.
Any recommendations on s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67718
Than McIntosh changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71396
Than McIntosh changed:
What|Removed |Added
CC||thanm at google dot com
--- Comment #1
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: thanm at google dot com
Target Milestone: ---
Created attachment 51008
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51008&action=edit
testcase to reproduce (Go files, some profile reports)
Building the a
24 matches
Mail list logo