Unit at a time and C PCH

[Jan Hubicka]

> 
> I don't think we do all that much inlining except at -O3.

Yep, I need to debug it. We should fit in 4GB for unit-at-a-time.
Mainline non-unit-at-a-time is doing somewhat better than tuples branch
needing about 2GB of RAM. So we would be still in regression land but it
is quite extreme testcase.

Problem is that compilation takes ages anyway
because of:
#0  0x00000000006b92b1 in decl_assembler_name_equal (decl=<value optimized out>, asmname=0x2aab56b35730) at ../../gcc/tree.c:325
#1  0x00000000006fd364 in cgraph_node_for_asm (asmname=0x2aab56b35730) at ../../gcc/cgraph.c:235
#2  0x00000000006c7b90 in find_decl_and_mark_needed (decl=<value optimized out>, target=0x2aab56b35730) at ../../gcc/varasm.c:5140
#3  0x00000000006c7c27 in finish_aliases_1 () at ../../gcc/varasm.c:5283 #4  0x00000000006ffc15 in cgraph_finalize_compilation_unit () at
../../gcc/cgraphunit.c:1075

There are very many aliases and cgraph_node_for_asm is doing linear
search of all nodes comparing the names, since simple string comparsion
don't work here (decl_assembler_name_equal is doing harder job here).

Do we actually need all those aliases?  We probably need to do some
hashing mechanizm for this, but I am not sure why we actualy need all
that mangling in decl_assembler_name_equal.

> 
> What is this .jar file, anyway?

It is jonas.jar.  I have no idea what it does, it is about 15MB.
I got it from someone during last round of dicussion on why Java needs
non-unit-at-a-time

HOnza
> 
> Andrew.