[cfe-dev] Memory and time consumption for larger files

[ihusar]

Hello,
   recently I encountered one rather unpleasant issue that
I would like to share with you.
   Me and few colleagues are working on a project where we want to
create a development environment for application-specific processor
processors (web pages, currently not much up-to-date are here:  
http://merlin.fit.vutbr.cz/Lissom/).
One part of this project is a compiler generator.
   To generate instruction selection patterns from our
architecture description language ISAC, one function that describes  
semantics of each
instruction is generated. File that contains these functions is then
compiled and contents of functions are optimized, so I get something quite  
close
to instruction selection patterns.
   For some architectures like ARM, the count of generated functions
is huge (e.g. 50000) and the resulting C file is huge too.

The problem here is that the compilation to LLVM IR using frontend takes
enormous amount of time and memory.

---------------------------------------------------------------------------------

Experiments are shown for C file or size 12 MB, functions have approx. 30  
lines each,
preprocessed file can be downloaded here:  
http://lissom.aps-brno.cz/tmp/clang-large-source.c.zip

   Tests were run on Fedora 11 64-bit, Pentium Quad Core, 2.83GHz, 4GB of  
memory.
Latest llvm and clang from llvm, rev. 99810, configured and compiled with  
--enable-optimized (uses -O2).
clang version 1.0  
(https://llvm.org/svn/llvm-project/cfe/branches/release_26 exported)

   Using GCC, gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2), time is only  
illustrative,
because also compilation into object file is included:
The top memory is just approximation observed from output of the top  
command.


1) g++ -DLISSOM_SEM -O0 -c -o tst.o clang-large-source.c
(time is only illustrative, because object code file is generated)
time: 12m17.064s
top memory approx: 2.6 GB


2) llvm-g++ -DLISSOM_SEM -O0 -c --emit-llvm -o tst.bc clang-large-source.c
time: 6m28.518s
top memory approx: 8 GB

3a) clang -DLISSOM_SEM -DCLANG -c -O0 -o tst.bc clang-large-source.c
time: 11m15.332s
top memory  approx 8 GB


   Resulting file tst.bc with debug info has 250 MB.
Without debug info  (-g0), compilation seems to be even slower, but it was  
maybe because
some swapping collision occurred, I was not patient enough to let it  
finish,
resulting file for llvm-g++ had 181 MB.

   Note also that on a 32-bit machine, the compilation would fail because  
of lack
of memory space.


   If I run then the opt -O3 on bc file generated with debug info,
it also consumes 7GB of memory and finishes in 9 minutes.

   In my opinion, 12 MB of source code is not so much and the compilation  
could be almost
immediate (or at least to be less than one minute), because no  
optimizations are made.
Especially, what i don't understand, is the big difference between code  
size and
the needed memory. After preprocessing, the C file has still 12MB, so  
roughly, each
byte from source file needs 660 bytes in memory, 20 bytes in resulting  
bytecode
and 100 bytes in disassembled bytecode.

-------------------------------------------------------------------------------------

Maybe there could be some batch mode that would parse the file by
smaller pieces, so the top memory usage would be lower.

   If I divide the file into smaller files, compilation takes much less  
time.
The question is, whether it is necessary, for example when -O0
is selected, to keep the whole program representation in memory.

time clang -DLISSOM_SEM -DCLANG -c -O0 -o tst.bc cg_instrsem_incl.c

for 2,5 MB file:
g++ (with obj. code generation): 1m 6s
llvm-g++: 7 s
clang: 2m2.501s

for 1 MB file:

g++ (with obj. code generation): 23 secs
llvm-g++: 2.5 s
clang time: 42 secs

   Here I do not much understand, why is clang so much slower than llvm-g++.
I checked, that it was configured with --enable-optimized more than once
(does this affect also the clang?).
Testing files can be found here:  
http://lissom.aps-brno.cz/tmp/clang_test.zip

------------------------------------------------------------------------------

Probably should this text go into bugzilla, but I thought it would be  
better
that more people would see it and maybe would be interested in the reason,  
why
clang behaves this way.
   Anyway, clang is a great piece of software and I am very looking forward  
to
see it replace gcc frontend with its cryptic error messages.
   However as the abstraction level of program description is
moving higher and higher, I am afraid it will not be uncommon to generate  
such
huge files from other higher-level languages that will use C as some kind  
of
universal assembler (as currently is done with Matlab or
some graphical languages).
   Such high memory and time requirements could pose problem for using  
clang as
compiler for generated C code.


   Or, do you have any ideas, when I would like to use clang, how to
make the compilation faster? (and of course, I already ordered more memory  
for my computer:).
   Also, if anyone would be more interested, what do I need to do with  
these files i need
to compile, you can write me an email.

Have a nice day
   Adam H.