[fortran-dev] constructor work, part I and II
Daniel Franke
franke.daniel@gmail.com
Wed Dec 30 11:11:00 GMT 2009
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: constructor-4.diff.gz
Type: application/x-gzip
Size: 25573 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20091230/d1b9430f/attachment.bin>
More information about the Gcc-patches
mailing list