On Fri, Apr 29, 2011 at 9:18 AM, Paolo Bonzini <bonz...@gnu.org> wrote: > 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! :).
If they are not growable then they are a candidate to replace sbitmaps (or bitmaps where sbitmaps are not used because the bitmap will be only sparsely populated). As usual most of the time improving the container implementation isn't the best kind of optimization. Instead exchanging the container type used or the algorithms will make more of a difference. > 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) Not so easy because C++ uses TREE_TYPE of it and thus you'd lose the nice sharing of identifiers. * Embed gimple_seq_node in gimple itself. This should simplify some iterators, avoid pointer indirection and eventually be more cache friendly. No idea why it wasn't done this way from the start. Richard. > Paolo >
