why 6Gb RAM not enough to compile a 14Mb source [MELT]?

[Basile STARYNKEVITCH]

Hello All,

my MELT branch http://gcc.gnu.org/wiki/MiddleEndLispTranslator has a big 
source file in it warm-basilys-0.c. It is "self" generated, about 
14Mbytes & almost 280KLOC (in rev136334). It ends with a big 
initialization routine of 100KLOC which mostly fills a 5000 member 
structure (each member being itself a small structure) and calls a few 
routines. This initialization routine has a simple control structure (no 
deeply nested blocks or loops).

But gcc (either gcc-4.1 or 4.2 or 4.3 from Debian, or the bootsrapped 
trunk rev136331) can compile this file without any optimisation ie with 
-O0 -g3 in about 16 seconds and less than 1Gb RAM.

But on my 6 Gbytes machine (Core2, 2400MHz, Debian/Sid/AMD64) the cc1 
process with -O2 (either 4.2, 4.3 or the trunk) eats  nearly 10Gb of 
virtual memory and trashes (using 4.8Gb of RAM, 1% cpu time, waiting for 
the swap IO). The same happens with -O1. -Os is a bit better.

The time to run the
./built-melt-cc-script warm-basilys-0.c warm-basilys-0.so
which compiles warm-basilys-0.c with -O2 -fPIC is

(you can set the MELT_EXTRACFLAGS environment variable to pass
real    84m23.594s
user    6m23.496s
sys     1m5.032s

I am attaching the -ftime-report output for information. One of the most 
demanding passes is tree operand scan

I find this report misleading on the memory consumption total (1591718kB 
= 1.6Gb). The top command gives that cc1 needs nearly 10Gb of process 
space, and uses nearly 5G (and trashes).

I won't be annoyed for long by this, since I'll soon split the 
warm-basilys.bysl file (and hence the generated files) in several 
distinct files. Until then, -O0 is enough for me.

Are there any specific flags to pass to gcc to lower the RAM consumption 
(even at the expense of generated code quality)?

Are there any pragma-s to disable (or lower) optimisation of a single 
routine?

My intuition (and experience) is that gcc -O2 (or even -O1) time and 
space consumption is nearly quadratic on the size of the longest routine.

Thanks for reading.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gcc-trunk-on-warm-basilys
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20080604/dca2c0df/attachment.ksh>