> Hello, > > as discussed in http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01133.html, > it might be a good idea to try moving cfg to alloc pools. The patch > below does that for basic blocks (each function has a separate pool > from that its basic blocks are allocated). At the moment, the patch > breaks precompiled headers, but otherwise bootstraps and passes > regtesting.
Since precompiled headers are C++ only that is unit-at-a-time, I think we can arrange things in cgraph so the functions are not lowered yet at PCH point. I tried this plan once and abadoned it because of some dificulties I forgot but I can try again. > > The problem is, that it does not give any speedups (it is almost > completely compile-time neutral for compilation of preprocessed > gcc sources). I will check whether moving also edges to pools > changes anything, but so far it does not seem very promising :-( Well, the benefits of these things are always very dificult to predict :(. We later tweaked ggc-page to put basic blocks into extra_order_size_table that ight've improved locality and get back some part of the original 1% slowdown. I would expect edges to be more interesting since they are smaller and there are more of them but I might be mistaken. This approach might be also very interesting for GIMPLE tuples once they arrive I woudl say so I like it in general. Honza
