https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #101 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:c57a8aea0c3ab8394f7dbfa417ee27b4613f63b7
commit r12-280-gc57a8aea0c3ab8394f7dbfa417ee27b4613f63b7
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #100 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:3f16a1678156035bbe73b217fbce4d9c27d1d559
commit r11-7254-g3f16a1678156035bbe73b217fbce4d9c27d1d559
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #99 from Richard Biener ---
Just a short brain-dump for the PTA issue:
--param max-fields-for-field-sensitive=1 helps, so some magic limit and
auto-degrading might be a good idea.
Solver stats are not so bad:
Total vars:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #98 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:6cc886bf4279461b8931c4ca544185a85cd69f26
commit r11-7208-g6cc886bf4279461b8931c4ca544185a85cd69f26
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #97 from Richard Biener ---
So fixing that makes GCC 11 compile the full testcase at -O1 -g in 18 seconds
using about 1GB of memory.
That leaves PTA at -O2+ as the biggest offender (it also shows up with the
reduced testcase).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #96 from Richard Biener ---
The full testcase on trunk (g:95d94b52ea8478334fb92cca545f0bd904bd0034) at -O0
-g
now takes 9s to compile and uses 1GB ram.
With -O1 -g we have
Time variable usr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #95 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:95d94b52ea8478334fb92cca545f0bd904bd0034
commit r11-7205-g95d94b52ea8478334fb92cca545f0bd904bd0034
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #94 from Richard Biener ---
Created attachment 50165
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50165=edit
patch experiment
(In reply to Jakub Jelinek from comment #93)
> I think I'd go for more chains by default, at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #93 from Jakub Jelinek ---
I think I'd go for more chains by default, at least 64 or even 256, with a
param and tracking on how many we have in a counter. The class has a
ctor/dtor, so the increment/decrement of the counter can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #92 from Richard Biener ---
Simple and stupid like the below works and does
store merging : 0.42 ( 1%) 0.00 ( 0%) 0.43 ( 1%)
3858k ( 1%)
TOTAL : 56.86 0.56
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #91 from Richard Biener ---
So the other simple idea I have is to limit the number of active store groups
and force-terminate in either a LRU or FIFO manner.
For the testcase at hand the decls we start the chain for are all only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #90 from Jakub Jelinek ---
Because it says that the whole range is uninitialized, so the store merging
code doesn't need to care about pre-existing content in any gaps between the
stored values. So say when the whole var is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #89 from Richard Biener ---
Fallout includes
FAIL: g++.dg/opt/store-merging-1.C scan-tree-dump store-merging "New sequence
of [12] stores to replace old one of 2 stores"
which shows
Starting new chain with statement:
s ={v}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #88 from rguenther at suse dot de ---
On Wed, 10 Feb 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
>
> --- Comment #87 from Jakub Jelinek ---
> At least for PR92038 it is important to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #87 from Jakub Jelinek ---
At least for PR92038 it is important to see CLOBBERs in the chain, including
the first position in there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #86 from Richard Biener ---
OK, so clobber handling was added as a fix for PR92038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #85 from Richard Biener ---
Starting new chain with statement:
D.31414 ={v} {CLOBBER};
The base object is:
Starting new chain with statement:
D.31415 ={v} {CLOBBER};
The base object is:
...
but those are all the last use of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #84 from Richard Biener ---
So it's the usual (quadratic) culprit:
Samples: 1M of event 'cycles:u', Event count (approx.): 1675893461671
Overhead Samples Command Shared Object Symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #82 from Jan Hubicka ---
> > Yep, this is because they used to be arrays indexed by symbol UIDs which
> > Martin converted to hash tables. Inliner happily calls summary_get each
> > time it needs the summary. I have some patches to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #81 from rguenther at suse dot de ---
On Tue, 6 Nov 2018, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
>
> --- Comment #80 from Jan Hubicka ---
> >
> > flat perf profile:
> >
> > Samples:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #80 from Jan Hubicka ---
>
> flat perf profile:
>
> Samples: 510K of event 'instructions:p', Event count (approx.): 715615147320
>
> Overhead Samples Command Shared Object Symbol
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #78 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Tue Dec 10 12:31:39 2013
New Revision: 205857
URL: http://gcc.gnu.org/viewcvs?rev=205857root=gccview=rev
Log:
2013-12-10 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #77 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Mon Dec 9 15:13:07 2013
New Revision: 205808
URL: http://gcc.gnu.org/viewcvs?rev=205808root=gccview=rev
Log:
2013-12-09 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #75 from Richard Biener rguenth at gcc dot gnu.org ---
On trunk with the reduced testcase and -O2 (no -g):
ipa inlining heuristics : 9.85 ( 5%) usr 0.00 ( 0%) sys 9.93 ( 5%) wall
1448 kB ( 0%) ggc
tree PTA:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #76 from Richard Biener rguenth at gcc dot gnu.org ---
There are a lot of calls with fnspec, almost all constraints look like
D.12770.0+16 = allalltmp
D.12770.64+128 = allalltmp
D.12770.192+64 = allalltmp
callarg = READONLY
callarg =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #74 from Richard Biener rguenth at gcc dot gnu.org 2013-03-07
14:55:27 UTC ---
(In reply to comment #73)
On trunk with the reduced testcase I now see PTA taking 90% of compile-time
...
Argh.
I can speed it up by
@@
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
30 matches
Mail list logo
