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]

Re: egcs/gcc patch to speed up compiles of some Fortran code


>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)


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