[patch, fortran] PR32489 and PR20923 Endless loop when compiling, slow for large array constrcutors

[Jerry DeLisle]

Hi folks,

I have combined the original patch for pr20923, previously approved. with the 
exploratory patch I posted earlier.  This patch speeds up certain compilations 
by doing two things.

If an array constructor is found to be already a constant, it can be traversed 
directly without calling gfc_is_constant_expr.  This provides significant speed 
up for the test cases in PR20923.  The speedup is due to avoiding the more 
complicated logic in gfc_is_constant_expr which must handle all expression 
types.  For large arrays. the time can add up fast.

The second improvement comes from observing that if an array constructor is not 
involved in a parameter, it need not be fully expanded.  See PR32489 for the 
fft257.f90 test case.  The new function, gfc_is_expandable_expr traverses the 
constructor and if it finds a variable with flavor FL_PARAMETER, it returns 
true, indicating to proceed with full expansion.

Parameters must be expanded fully because they need to be used by the gfortran 
front-end to build other expressions.  Expressions that are not related to 
parameters do not need to be fully expanded (unrolled).  The troublesome 
expression in fft257.f90 is currently expanded fine by the gfortran front-end, 
but the resulting complexity bogs down the middle-end completely.  With this 
patch, the complex expression is simply translated into a few loops, allowing 
the middle-end to optimize where possible.

I have provided some test results below.

Regression tested on x86-64.  OK for trunk?

Regards,

Jerry

2009-12-13 Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/20923
	PR fortran/32489
	* trans-array.c (gfc_conv_array_initializer): Change call to
	gfc_error_now to call to gfc_fatal_error.
	* array.c (count_elements): Whitespace. (extract_element): Whitespace.
	(is_constant_element): Changed name from constant_element.
	(gfc_constant_ac): Only use expand_construuctor for expression
	types of EXPR_ARRAY.  If expression type is EXPR_CONSTANT, no need to
	call gfc_is_constant_expr.
	* expr.c (gfc_reduce_init_expr): Adjust conditionals and delete error
	message.
	* resolve.c (gfc_is_expandable_expr): New function that determiners if
	array expressions should have their constructors expanded.
	(gfc_resolve_expr): Use new function to determine whether or not to call
	gfc_expand_constructor.

Some test results:

1) fft257.f90 failed to complete compilation on my system after 448 minutes. 
Reducing the size of the problem from N=257 to N=75 and commenting out the call 
to fft257 to avoid compile errors from mismatched array size, we get the 
following compile times.

gfortran unpatched:

real	0m20.792s
user	0m20.226s
sys	0m0.544s

gfortran patched:

real	0m1.713s
user	0m1.626s
sys	0m0.076s

2) With the original test case in pr20923.

gfortran unpatched:

real	0m8.239s
user	0m8.202s
sys	0m0.033s

gfortran patched:

real	0m2.128s
user	0m2.106s
sys	0m0.022s

3) Parameter test case from pr34554.
    (Difference is not significant)

gfortran unpatched:

real	2m6.507s
user	2m6.461s
sys	0m0.017s

gfortran patched:

real	2m5.835s
user	2m5.784s
sys	0m0.022s



-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-3.diff
Type: text/x-patch
Size: 5618 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20091214/a9d64a26/attachment.bin>