This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: TREE_CODE mania
- From: Devang Patel <dpatel at apple dot com>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 4 Sep 2002 10:19:49 -0700
- Subject: Re: TREE_CODE mania
On Tuesday, September 3, 2002, at 08:51 PM, Daniel Berlin wrote:
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?
Sure, we can try using different allocation schemes to achieve better compile
time performance. But this approach is like -- earn more money and allocate
funds in better way to meet the budget. I am thinking in terms, can we reduce
expenditure ? I think, we need to work in both direction to achieve better
compile time speedup.
-Devang