This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: egcs/gcc patch to speed up compiles of some Fortran code
- To: rth at cygnus dot com
- Subject: Re: egcs/gcc patch to speed up compiles of some Fortran code
- From: Craig Burley <burley at gnu dot org>
- Date: Mon, 25 May 1998 02:33:24 -0400 (EDT)
- CC: egcs at cygnus dot com, law at cygnus dot com, d dot love at dl dot ac dot uk
>On Sat, May 23, 1998 at 12:18:09PM -0400, Craig Burley wrote:
>> + static int save_expr_count;
>> + static int save_expr_size = 0;
>> + static tree *save_expr_rewritten;
>> + static tree save_expr_trees[256];
>
>Perhaps a stylistic preference, but it would seem to me that a
>simple linked list of malloced nodes, or a TREE_CHAIN, would be
>a better way to handle this. Thus avoiding the array resizing
>issue.
I didn't look to see whether SAVE_EXPR nodes had a free TREE_CHAIN
pointer at that stage, and didn't want to worry about resizing at
all until it became clear it was needed. So save_expr_rewritten
could actually be eliminated, replaced with save_expr_trees, etc.
In the meantime, no malloc'ing is done at all.
I'm more worried about the appropriateness of even-temporarily
rewriting the code of a node via TREE_SET_CODE. Maybe a better
approach is to stuff a special "reserved" RTL node into the
third operand, where RTL info normally goes, of the SAVE_EXPR.
In that case as well, there's no need to save what was already
there; we know it's zero (a null pointer). So all we need, as
in the current code, is a pointer to the tree node itself so we
can restore that zero pointer.
Earlier I thought this patch could be just like the way
contains_placeholder_p works, in that the rewrite would just
avoid *recursive* calls for the same tree node doing anything
substantial. Turns out that didn't solve the problem; the
bushiness doesn't arise from SAVE_EXPRs that reference themselves,
which I should have remembered before even trying that approach.
tq vm, (burley)