This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: TREE_CODE mania
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Devang Patel <dpatel at apple dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 3 Sep 2002 23:51:02 -0400 (EDT)
- Subject: Re: TREE_CODE mania
On Tue, 3 Sep 2002, Devang Patel wrote:
> Hi All,
>
> Recently there was a discussion about faster compile time. And
> memory usage and/or allocation is considered one probable
> culprit behind the slow compiler.
>
> To understand actual memory usage pattern, I instrumented GCC
> by replacing TREE_CODE macro with function TREE_CODE_read().
> I just wanted to see what is the usage pattern and how bad/good is it.
>
> I collected profiled data for following one line program.
>
> int foo() { return 1;}
>
> Now, gprof tells me that to compile this, cc1 calls TREE_CODE_read()
> 37572 times! I was expecting that number to be in couple of thousands
> range but 37k seems high to me.
>
> I think, such a high number of indirect memory references puts
> high pressure on VM and GCC's memory manager to maintain locality.
Which it doesn't.
Can't we attack this problem directly?
By maybe using object based bins rather than size based ones, at least for
trees and RTL?
ggc_alloc_rtx and ggc_alloc_tree are just defined to call ggc_alloc, but
we could change this to do that, no?
Maybe these types of objects are special enough that even though they may
have different sizes (IE different RTL objects have different sizes), they
should be in the same bins anyway.
Then we'd have the locality for our most used objects.
Do we really care about locality for many other things anyway?