On 06/16/2014 10:01 AM, Jan Hubicka wrote:
On 06/10/2014 08:34 AM, Jan Hubicka wrote:
Hi,
ipa-reference is somewhat stupid and builds its data sets for all variables
including
addressable and public one just to prune them out after all bitmaps are
constructed.
This used to make sense when the profile generation happened at compile time,
but
since ipa_ref datastructure was intrdocued this is a nonsense.
Martin: It may be interesting to check if this solves the memory use issues with
chrome. We also may be able to re-enable ipa-ref with profile-generate as
I think all the datastructures are considered to have address taken.
Hi,
there is a link to chromium stats:
https://drive.google.com/file/d/0B0pisUJ80pO1VmNHeklCRWVkOUU/edit?usp=sharing
Both compilation were run with '-flto=6', where the upper graph adds
'-fprofile-generate'. Memory footprint is IMHO acceptable, but compilation
process takes twice longer with profile generation. Yeah, chromium contains a
really big code base :)
Yep, I wonder why WPA takes so much longer. Do you think you can build lto1
with --enable-gather-detailed-mem-stats and relink with -fpre-ipa-mem-report
-fpost-ipa-mem-report -fmem-report -Q and send me the output? It would be nice
to push Chromium under 4GB of WPA :)
There's report you requested:
https://drive.google.com/file/d/0B0pisUJ80pO1RlRRTVBxUG5vSlE/edit?usp=sharing ,
produced by -fno-profile-generate. With enabled -fprofile-generate, WPA stage
cannot fit to 24GB memory with enabled memory stats.
Martin
Thanks a lot!
Honza
