This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]