On 04/27/2011 03:28 PM, Yuan Pengfei wrote:
Any other advice will be appreciated.
I think you can look into llvm-clang. It compiles faster and uses
much less memory than gcc.
It is also a completely different compiler. It doesn't make sense to
compare the two, unless Dimitrios wants to rewrite GCC in 3 months.
Joe's suggestion (take a look at the "speedup areas" page, investigate
which bullets can still be a priority) and talking to Nicola to help him
with benchmarks and get up to speed with the code, are the best in this
thread.
Regarding bitmaps, I have patches to use vector instructions. The
compile-time difference was basically a wash, but I can give them to you
if you are interested. Alternatively, the ebitmap.[ch] files in GCC are
totally unused, and better in theory. The main hurdle is that ebitmaps
are not growable. Still, they should be usable in many cases (or they
can be made growable! :).
A nice exercise to get up to speed with the code is to make GCC record a
set of bitmap operations from real compilation, and then have a driver
that uses that set of operations for benchmarking. This is the only
sane way to extract the real performance of the data structure. It
doesn't avoid the need for validation in the compiler, of course, where
other effects can come into play (caching etc.), but it is a useful start.
From the list in the webpage, the following items should be easier than
the others:
* Split simulate_stmt into simulate_stmt and simulate_phi because the
caller of simulate_stmt knows whether it's got a statement or a PHI node.
* Get rid of EXPR_LIST and INSN_LIST
* cxx_binding should be 16 bytes, not 20.
* Eliminate binfos for POD structs and other no-inheritance classes (not
so easy)
* Put the string at the end of the IDENTIFIER_NODE using the trailing
array hack (or possibly in the ht_identifier, see
libcpp/include/symtab.h and libcpp/symtab.c)
Paolo
