https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
David Edelsohn changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
Richard Biener changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #24 from Richard B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #23 from Aldy Hernandez ---
I have built a cross to ppcle on gcc135 (ppc64le) and then bisected the lowest
amount of memory ./cc1 -O2 can compile rlwimi-1.c (via ulimit -v).
Before the VRP threader replacement it could run with 271m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #22 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:64dd46dbc682fbbc03a74e0298f7ac471c5e80f2
commit r12-3974-g64dd46dbc682fbbc03a74e0298f7ac471c5e80f2
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #21 from Aldy Hernandez ---
However, if you care to test a patch, I'd be happy to review it.
On Thu, Sep 30, 2021 at 7:49 AM aldot at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
>
> Bernhard Reutn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #20 from Aldy Hernandez ---
Doesn't make a difference. If the blocks are stale, they need to be
reconstructed anyhow. It's preexisting behavior in VRP anyhow.
I heard you the first time ;-).
On Thu, Sep 30, 2021 at 7:49 AM aldot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
Bernhard Reutner-Fischer changed:
What|Removed |Added
CC||aldot at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #18 from David Edelsohn ---
Yea! That fixes the *worst* of the memory growth problem for me.
It still is growing, but much more slowly. RSS now grows from 569788 to 642076
for the final function, instead of 783896 before it died o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #17 from Jeffrey A. Law ---
Consider that pre-approved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #16 from Aldy Hernandez ---
On Wed, Sep 29, 2021 at 10:46 PM dje at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
>
> --- Comment #15 from David Edelsohn ---
> I annotated execute_vrp_threader() to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #15 from David Edelsohn ---
I annotated execute_vrp_threader() to call getrusage() and print the size of
RSS around each call to threader.thread_jumps(). It consistently is growing,
but not in the threader itself. Was the former VP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #14 from David Edelsohn ---
I tried the patch, but, unfortunately, it exceeds the memory limit in the same
manner.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #13 from Aldy Hernandez ---
Created attachment 51520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51520&action=edit
avoid CFG and SSA updates when possible
The VRP threader is updating SSAs and CFG even if nothing changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #12 from David Edelsohn ---
GCC non-quiet mode shows:
...
g_31_31_16 f_31_31_17 g_31_31_17 f_31_31_23 g_31_31_23 f_31_31_24 g_31_31_24
f_31_31_25 g_31_31_25 f_31_31_29 g_31_31_29 f_31_31_30 g_31_31_30 f_31_31_31
g_31_31_31
Analyzing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #11 from David Edelsohn ---
tree VRP threader : 0.25 ( 2%) 0.03 ( 1%) 0.76 ( 1%)
7804k ( 2%)
Despite that report output, prior to the two patches ending with
ef1e524fd87a679f5da06116029c66a84daac80 "Remov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #10 from Aldy Hernandez ---
The attached patch adds a separate TV_* timer to see the actual break down for
VRP and the VRP threader.
Could you incorporate this patch and run the problematic file with ./cc1
-ftime-report -O2? I'd li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #9 from Aldy Hernandez ---
Created attachment 51519
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51519&action=edit
patch to help diagnose issue with -ftime-report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #8 from Aldy Hernandez ---
(In reply to David Edelsohn from comment #7)
> Have you tried a native PPC64LE Linux build?
>
> AIX defaults to 32 bit, and it's big endian. I wouldn't expect that to
> affect the memory usage, but I'm men
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #7 from David Edelsohn ---
Have you tried a native PPC64LE Linux build?
AIX defaults to 32 bit, and it's big endian. I wouldn't expect that to affect
the memory usage, but I'm mentioning it.
Did you try to compiler gcc/testsuite/gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #6 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Aldy Hernandez from comment #4)
> > Is there any way of reproducing this on a cross? I've been waiting 15
> > minutes for a "git fetch" on gcc111.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #5 from Andrew Pinski ---
(In reply to Aldy Hernandez from comment #4)
> Is there any way of reproducing this on a cross? I've been waiting 15
> minutes for a "git fetch" on gcc111.fsffrance.org or gcc119.fsffrance.org.
> I'll cont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #4 from Aldy Hernandez ---
Is there any way of reproducing this on a cross? I've been waiting 15 minutes
for a "git fetch" on gcc111.fsffrance.org or gcc119.fsffrance.org. I'll
continue trying in the background just in case.
FWIW,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
--- Comment #3 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
David Edelsohn changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
25 matches
Mail list logo
