This is the mail archive of the gcc-patches@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



  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


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