| Summary: | GCC uses up to 75GB of virtual memory | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Alex Queiroz <alex> |
| Component: | middle-end | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | abel |
| Priority: | P3 | Keywords: | memory-hog |
| Version: | 4.7.0 | ||
| Target Milestone: | 4.7.0 | ||
| Host: | Target: | ||
| Build: | Known to work: | 4.7.0 | |
| Known to fail: | Last reconfirmed: | 2012-01-24 00:00:00 | |
| Bug Depends on: | |||
| Bug Blocks: | 47344 | ||
| Attachments: |
test file to reproduce the problem
Proposed patch |
||
This has many computed gotos in the source. Confirmed. We have a loop with a couple thousands of bbs and >20k datarefs, and we die in a quadratic loops in compute_all_dependences. Can be easily fixed with a PARAM limiting the data ref analysis. While doing this, I noticed that there is no reason for find_data_references_in_loop to be extern and made it static. Also predcom and parloops are not ready for compute_data_dependences_for_loop returning false, so I fixed this as well. Created attachment 26441 [details]
Proposed patch
The patch described above.
Author: abel Date: Fri Jan 27 13:47:41 2012 New Revision: 183624 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183624 Log: PR middle-end/51389 * Makefile.in (tree-data-ref.o): Depend on $(PARAMS_H). * tree-data-ref.h (find_data_references_in_loop): Remove declaration. * tree-data-ref.c (find_data_references_in_loop): Make static. (compute_all_dependences): Change return type to bool. Bail out for too many datarefs in a loop. Move the hunk resetting the data dependences vector from ... (compute_data_dependences_for_loop): ... here. Account for compute_all_dependences returning false. (compute_data_dependences_for_bb): Likewise. * params.def (PARAM_LOOP_MAX_DATAREFS_FOR_DATADEPS): New param. * doc/invoke.texi (loop-max-datarefs-for-datadeps): Document it. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/doc/invoke.texi trunk/gcc/params.def trunk/gcc/tree-data-ref.c trunk/gcc/tree-data-ref.h Fixed for 4.7.0. If this is fixed for GCC 4.7, why leave the bug report open? Do you plan to back-port a similar fix to older release branches? Fixed. |
Created attachment 25971 [details] test file to reproduce the problem When compiling the attached file, GCC uses up to 75GB of virtual memory, which causes swapping and slows down the compilation a lot. Command line: /opt/local/bin/gcc-mp-4.7 -save-temps -Wno-unused -O3 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fmodulo-sched -freschedule-modulo-scheduled-loops -march=core2 -fomit-frame-pointer -fPIC -fno-common -mieee-fp -I"../include" -c -o "_t-c-2.o" -I. -DHAVE_CONFIG_H _t-c-2.c -D___LIBRARY System: Darwin alexs 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64 i386 GCC: Using built-in specs. COLLECT_GCC=/opt/local/bin/gcc-mp-4.7 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.0/lto-wrapper Target: x86_64-apple-darwin11 Configured with: ../gcc-4.7-20111126/configure --prefix=/opt/local --build=x86_64-apple-darwin11 --enable-languages=c,c++,objc,obj-c++ --libdir=/opt/local/lib/gcc47 --includedir=/opt/local/include/gcc47 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.7 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.7 --with-gxx-include-dir=/opt/local/include/gcc47/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --disable-multilib Thread model: posix gcc version 4.7.0 20111126 (experimental) (GCC)