This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: egcs/gcc patch to speed up compiles of some Fortran code
- To: Craig Burley <burley at gnu dot org>
- Subject: Re: egcs/gcc patch to speed up compiles of some Fortran code
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Thu, 04 Jun 1998 01:26:07 -0600
- cc: egcs-patches at cygnus dot com, d dot love at dl dot ac dot uk
- Reply-To: law at cygnus dot com
In message <199806031640.MAA03835@melange.gnu.org>you write:
> Because it doesn't matter in this case. There *is* no arbitrary
> limit here, in the sense meant by most people (e.g. the GNU coding
> guidelines).
>
> The safe_from_p returns a boolean answer to the following question:
>
> Can you prove that evaluating expression EXP cannot possibly reference
> anything in X?
>
> (Or similar...the "can you prove" is the essential element.)
OK. Sorry, I didn't mean for you to go through quite as much detail
as you did. Basically I was worried that the arbitrary limit would
either:
a. I rarely work with trees and thus some things which may
seem obvious to you aren't quite as obvious to me.
So I was somewhat worried that just returning zero when
the array got big could be a problem. It's obvious now
that such an action is 100% safe, but it wasn't when
I initially read the patch.
Maybe a better comment before the return statement is
in order. Also note, comments should be on separate
lines, not tacked onto the end of a line with code:
! if (save_expr_count >= save_expr_size)
! return 0; /* For now, don't bother re-sizing the array. */
b. The other concern was that the limit could cause the
compile time explosion to occur in more complex
expressions. But it's obvious now that returning zero
when the number of SAVE_EXPRs gets high can never have
that effect.
Your answer above makes it quite clear that neither of those problems
can happen. Thus, we just fall into the style question, which wasn't
a major concern of mine for this code.
> P.S. I *think* what this means is that, essentially, my original
> patch has no agreed-upon problems with it. The one exception might
> be that I should submit a patch to improve the commentary at the
> head of safe_from_p. Here goes, though it isn't in patch form:
Yes. Actually, a clearer comment in the function header is the
right place. I'd suggest just adding this after the existing text:
It is always safe for this routine to return zero since it merely
searches for optimization opportunities.
I'll apply your patch, tweak the one mal-formed comment in the code
and update the function header's comments.
jeff