https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #41 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:257c2be7ff8dfdc610202a1e1f5a8a668b939bdb
commit r14-1165-g257c2be7ff8dfdc610202a1e1f5a8a668b939bdb
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #40 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:cfd6569e9c41181231a8427235d0c0a7ad9262e4
commit r14-1164-gcfd6569e9c41181231a8427235d0c0a7ad9262e4
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #39 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:d8b058d3ca4ebbef5575105164417f125696f5ce
commit r14-1163-gd8b058d3ca4ebbef5575105164417f125696f5ce
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #38 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #37)
> (In reply to CVS Commits from comment #36)
>
> > For the curious, a particular hot spot for IPA in this area was:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #37 from Andrew Macleod ---
(In reply to CVS Commits from comment #36)
> For the curious, a particular hot spot for IPA in this area was:
>
> ipcp_vr_lattice::meet_with_1 (const value_range *other_vr)
> {
> ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #36 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:76e11280e79c5dd5089c17d5726cae9a5a21bc2e
commit r14-862-g76e11280e79c5dd5089c17d5726cae9a5a21bc2e
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #35 from Aldy Hernandez ---
We could also tweak the number of sub-ranges. 8 (??) also sounds good for a
few percent less in performance drop, if we care.
p.s. I did try the auto_vec thing for a 25% loss in VRP performance, even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #34 from Aldy Hernandez ---
Excellent ideas!
For that matter, we may get away with defaulting to 3 sub-ranges and always
resizing as needed (up to MAX). Needing more than 3 sub-ranges is so rare
(less than 0.5% of the time), that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #33 from Jakub Jelinek ---
That would indeed simplify things and auto_vec member would be unnecessary, nor
any of the length/allocated members etc. All we'd need is just a pointer and
small size buffer (and is_small check would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #32 from rguenther at suse dot de ---
On Tue, 9 May 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
>
> --- Comment #29 from Jakub Jelinek ---
> Comment on attachment 55031
> -->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #31 from Jakub Jelinek ---
Well, you don't need to use {,vec_}{safe,quick}_push etc. all the time, just
have auto_vec in there and use .address () on it to give you pointer to the
elements and then .length () / .allocated () and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #30 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #29)
> Comment on attachment 55031 [details]
> WIP patch for a dynamic int_range<>
>
> What I meant is that by using a auto_vec could avoid reimplementing larger
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #29 from Jakub Jelinek ---
Comment on attachment 55031
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55031
WIP patch for a dynamic int_range<>
What I meant is that by using a auto_vec could avoid reimplementing larger
chunks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #28 from Aldy Hernandez ---
Created attachment 55031
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55031=edit
WIP patch for a dynamic int_range<>
Here's my WIP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #27 from rguenther at suse dot de ---
On Tue, 9 May 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
>
> --- Comment #26 from Jakub Jelinek ---
> new/delete rather than auto_vec member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #26 from Jakub Jelinek ---
new/delete rather than auto_vec member inside of the type using new/delete?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #25 from Richard Biener ---
(In reply to Aldy Hernandez from comment #24)
> FYI. I originally tried new/delete for allocation, which was a tad slower
> than ggc_alloc / ggc_free. Not too much, but measurable.
>
> Another idea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #24 from Aldy Hernandez ---
FYI. I originally tried new/delete for allocation, which was a tad slower than
ggc_alloc / ggc_free. Not too much, but measurable.
Another idea would be to have a global obstack which auto_int_range<>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #23 from Aldy Hernandez ---
An update on the int_range_max memory bloat work.
As Andrew mentioned, having int_range<25> solves the problem, but is just
kicking the can down the road. I ran some stats on what we actually need on a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #22 from Andrew Macleod ---
OK, I've finished with my analysis. There are multiple vectors of attack here,
and we should do them all. Some where already on my radar for this release
anyway, but this gives a nice tidy place to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #21 from David Binderman ---
Two cases, depending on the text of the warning:
$ fgrep warning: mk.out | fgrep Wstack | fgrep -v "might be unbounded" | fgrep
"usage is" | sort -rnk 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #20 from David Binderman ---
(In reply to Jakub Jelinek from comment #17)
> Or just try to check for functions with largest stack usages in cc1plus?
> Doing that on the trunk gives:
> objdump -dr cc1plus | grep
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #19 from rguenther at suse dot de ---
On Thu, 4 May 2023, aldyh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
>
> Aldy Hernandez changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #17 from Jakub Jelinek ---
For peak memory consumption there is -fmem-report, which prints stats about GC
memory.
For this PR I think you want instead measure maximum stack usage.
Perhaps GCC could be built with -fstack-usage and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #15 from Andrew Macleod ---
(In reply to Mikael Morin from comment #8)
> (In reply to Andrew Macleod from comment #7)
> >
> > diff --git a/gcc/gimple-range.cc b/gcc/gimple-range.cc
> > index 49e9d6b4de6..74afaaf2989 100644
> > ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #14 from Jakub Jelinek ---
I think even 4080 bytes for int_range_max was quite a lot. I know it perhaps
simplifies stuff a little bit and hopefully copy construction/assignments only
copy the actual ranges and not the whole thing,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #13 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #12)
> Perhaps change int_range to have the wide_ints as auto_vec with reserved
> space for a few (perhaps 3 (times 2))?
Our original implementation was exactly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #12 from Jakub Jelinek ---
Perhaps change int_range to have the wide_ints as auto_vec with reserved space
for a few (perhaps 3 (times 2))?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #11 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #7)
> The problem was exposed by the newly increased size of int_range_max. (We
> may want to address that elsewhere) It has grown an order of magnitude in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #7 from Andrew Macleod ---
Created attachment 54973
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54973=edit
Patch to fix the issue
The problem was exposed by the newly increased size of int_range_max. (We may
want to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #6 from Aldy Hernandez ---
I forgot to add. Running with "ulimit -s unlimited" does not segfault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #5 from Andrew Macleod ---
have a look at the changes in waccess... this compiles fine with
--disable-tree-waccess1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2023-05-02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
Richard Biener changed:
What|Removed |Added
Version|13.0|14.0
Component|c
42 matches
Mail list logo
