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: Wed, 4 Sep 2002 19:04:15 -0400
- Subject: Re: TREE_CODE mania
On Wednesday, September 4, 2002, at 01:19 PM, Devang Patel wrote:
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 ?
By the by, did you mark the TREE_CODE_read function as const/pure (i'm
not sure tree_code's aren't modified in place, if they are, it's both,
if they aren't, it's at least one of them), so that it accurately
simulates the macro in terms of actual accesses?
I think, we need to work in both direction to achieve better
compile time speedup.
-Devang