[fortran-dev] constructor work, part I and II

[Daniel Franke <franke dot daniel at gmail dot com>]

Follow-up to
	http://gcc.gnu.org/ml/fortran/2009-12/msg00167.html
	http://gcc.gnu.org/ml/fortran/2009-12/msg00170.html

On Wednesday 23 December 2009 17:37:01 Daniel Franke wrote:
> as mentioned a couple of times before, I'd like to get rid of linked lists
>  for constructurs. Instead, a more suitable tree structure should be used.
> 
>  (a) define an API that hides the implementation details of constructors
>  (b) apply the API everywhere where the linked-list implementation is used
>      directly
>  (c) reimplement the API functions using a different data structure

As the initial patch and the update did not get a formal review yet, I 
continued to work on it. Here's the whole of (a), (b) and (c) in one big 
changeset. It bootstraps and regtests fine up to one regression where I'm not 
sure it's a real regression or not a latent bug uncovered by the changes 
(char_component_initializer_1.f90). Either way, I didn't manage yet to get rid 
of it yet. There are also issues with this testcase in trunk as well (see 
PR42526).

What's left to do: merge array.c (gfc_get_array_element) and expr.c 
(find_array_element) into constructor.c (gfc_constructor_lookup). The first is 
not easily removed as it implicitly expands arrays not expanded yet. Jerry's 
patch might help there. Further, some simplifiers still iterate over all 
elements (see ADVANCE macro in simplify.c), these simplifiers need to be 
reimplemented for direct element access. 

Here's a comparison of current trunk vs. fortran-dev + patch, both applied to 
the currently known compile-time-hogs. Each testcase was run three times on 
i686-pc-linux-gnu (CoreDuo, 2.66 Ghz), average values are shown in seconds.

Flags used: -Wall -fmax-array-constructor=100000000

				trunk		fortran-dev + patch
initialization-21.f90 [1]	    1.2	 	  1.7
PR20923				   20.8		 22.7
PR28974	[2]			    1.9		  2.0
PR34554				  209.3		226,4
PR40472				>6000.0		 27.2

[1] the performance regression of the initial patch
[2] not so much a compile-time-hog since the initial use of splay-trees

It seems that on one hand, compile times even got worse - all those tests are 
of the "complicated init-expr" kind. The one test that significantly improved 
is the simplification of SPREAD - which mainly requires a quick insert. It 
needs to be seen what impact the to-do items listed above have on these 
findings.

Bootstrapped and regression tested on i686-pc-linux-gnu. On regression as 
described above. Nonetheless ok for fortran-dev (with a very long ChangeLog)?

Cheers

	Daniel

Attachment: constructor-4.diff.gz
Description: GNU Zip compressed data