https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #32 from Martin Jambor ---
(In reply to Martin Jambor from comment #30)
> I think that using the same approach to cache ipa_vr
> structures (used to store results of IPA-VR) could bring further
> savings
They were not really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #30 from Martin Jambor ---
With the above commit, we hae avoided the vast majority of memory use
increase. I think that using the same approach to cache ipa_vr
structures (used to store results of IPA-VR) could bring further
savings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #29 from Martin Jambor ---
Author: jamborm
Date: Wed Mar 1 09:37:27 2017
New Revision: 245805
URL: https://gcc.gnu.org/viewcvs?rev=245805=gcc=rev
Log:
[PR 78140] Reuse same IPA bits and VR info
2017-03-01 Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #28 from Martin Jambor ---
(In reply to Martin Jambor from comment #27)
> Unfortunately, something else has added a further gigabyte to WPA of
> FF in the last week:
So this fortunately turnout to be a mistake in measurement, I was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #27 from Martin Jambor ---
I have submitted a patch to the mailing list, which re-uses
value_ranges and ipa_bits in jump functions and manages to save more
than one gigabyte of memory:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #25 from Martin Liška ---
Created attachment 40549
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40549=edit
GCC 7 -fmem-report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #24 from Martin Liška ---
Created attachment 40548
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40548=edit
GCC 6 -fmem-report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #23 from Martin Liška ---
Depending on memory layout of the structure, but these 2 structures increase
memory of about ((32+88)*3258685)/(1024**2) ~372 MB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |jamborm at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #21 from Martin Liška ---
Looking at distinct number of value ranges and bits, we can get:
grep hash_vr /tmp/7.dump.ipa | sort | uniq -c | wc -l
65224
grep hash_bits /tmp/7.dump.ipa | sort | uniq -c | wc -l
13421
Where total # of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #20 from Richard Biener ---
Look at tree-ssanames.c:range_info_def for "tricks" (make them variable size):
/* Value range information for SSA_NAMEs representing non-pointer variables.
*/
struct GTY ((variable_size)) range_info_def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
Jan Hubicka changed:
What|Removed |Added
CC||kuganv at linaro dot org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #18 from Martin Liška ---
Created attachment 40545
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40545=edit
GCC 7 graph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #17 from Martin Liška ---
Created attachment 40544
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40544=edit
GCC 6 graph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #16 from Martin Liška ---
It's still reproducible with current trunk, it's over 1GB on my development
machine. I did a simple script that dumps sizes of all LTO object loaded to
WPA:
GCC 7:
asm : 19.67 KB
profile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #15 from Jan Hubicka ---
How does the memory use look with current tree?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #13 from Markus Trippelsdorf ---
(In reply to Martin Liška from comment #12)
> (In reply to Markus Trippelsdorf from comment #11)
> > js/src/jit/BaselineCompiler.cpp
>
> Hm, I see the R0 defined as:
>
> # 1
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #12 from Martin Liška ---
(In reply to Markus Trippelsdorf from comment #11)
> js/src/jit/BaselineCompiler.cpp
Hm, I see the R0 defined as:
# 1
"/home/marxin/BIG/buildbot/slave/source/firefox/js/src/jit/x64/SharedICRegisters-x64.h"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #11 from Markus Trippelsdorf ---
js/src/jit/BaselineCompiler.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #10 from Martin Liška ---
(In reply to Markus Trippelsdorf from comment #9)
> (In reply to Martin Liška from comment #8)
> > (In reply to Markus Trippelsdorf from comment #7)
> > > BTW Firefox trunk fails to build for me:
> > >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #9 from Markus Trippelsdorf ---
(In reply to Martin Liška from comment #8)
> (In reply to Markus Trippelsdorf from comment #7)
> > BTW Firefox trunk fails to build for me:
> >
> > ld: error: /tmp/ccsbLieS.ltrans29.ltrans.o: requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #8 from Martin Liška ---
(In reply to Markus Trippelsdorf from comment #7)
> BTW Firefox trunk fails to build for me:
>
> ld: error: /tmp/ccsbLieS.ltrans29.ltrans.o: requires dynamic R_X86_64_PC32
> reloc against '_ZN2js3jitL2R0E'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #7 from Markus Trippelsdorf ---
BTW Firefox trunk fails to build for me:
ld: error: /tmp/ccsbLieS.ltrans29.ltrans.o: requires dynamic R_X86_64_PC32
reloc against '_ZN2js3jitL2R0E' which may overflow at runtime; recompile with
-fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #5 from Markus Trippelsdorf ---
Similar picture on ppc64le (this uses a much older version of Firefox,
so overall memory usage is lower):
gcc7: Execution times (seconds)
phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #4 from Markus Trippelsdorf ---
Basicaly just "-O3 -flto".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
Richard Biener changed:
What|Removed |Added
Keywords||lto
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #1 from Markus Trippelsdorf ---
Created attachment 39915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39915=edit
gcc-6 memory graph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #2 from Markus Trippelsdorf ---
Created attachment 39916
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39916=edit
gcc-7 memory graph
33 matches
Mail list logo
