[Bug fortran/20923] Compile time is high for the following code

[Bug fortran/20923] Compile time is high for the following code

[jvdelisle at gcc dot gnu dot org]

------- Comment #5 from jvdelisle at gcc dot gnu dot org  2006-09-10 05:05 -------
This bug is related to slow compile found in test case for PR28914 with large
array size.  Constructor related.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] Compile time is high for the following code

[burnus at gcc dot gnu dot org]

------- Comment #6 from burnus at gcc dot gnu dot org  2007-03-21 21:56 -------
*** Bug 31301 has been marked as a duplicate of this bug. ***


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] Compile time is high for the following code

[burnus at gcc dot gnu dot org]

------- Comment #7 from burnus at gcc dot gnu dot org  2007-06-25 08:02 -------
*** Bug 32489 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[tobi at gcc dot gnu dot org]

------- Comment #8 from tobi at gcc dot gnu dot org  2007-10-06 14:08 -------
There's no related bug field, but it's worth mentioning that PR19925 and this
should probably be attacked at the same time.


-- 

tobi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Compile time is high for the|gfortran slow for large
                   |following code              |array constructors


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[tobi at gcc dot gnu dot org]

------- Comment #9 from tobi at gcc dot gnu dot org  2007-10-06 14:43 -------
And this looks like the right place for an attack:
/* Given an array constructor, determine if the constructor is
   constant or not by expanding it and making sure that all elements
   are constants.  This is a bit of a hack since something like (/ (i,
   i=1,100000000) /) will take a while as* opposed to a more clever
   function that traverses the expression tree. FIXME.  */

int
gfc_constant_ac (gfc_expr *e)
{


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[burnus at gcc dot gnu dot org]

------- Comment #10 from burnus at gcc dot gnu dot org  2008-01-13 23:00 -------
See also notes/patch attempt in PR 32489.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[jvdelisle at gcc dot gnu dot org]

------- Comment #11 from jvdelisle at gcc dot gnu dot org  2009-11-22 18:56 -------
Also see PR 41807 for related info.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[jvdelisle at gcc dot gnu dot org]

------- Comment #12 from jvdelisle at gcc dot gnu dot org  2009-11-27 07:31 -------
Created an attachment (id=19161)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19161&action=view)
Preliminary patch

This patch cuts the compilation time of the original test case in half.  It
passes all regression tests except initialization_20.f90.  I think this is an
example of case that relies on a side effect to work.  If we can resilve this
one regression we will make substantial progress.  The failing test case needs
expansion/reduction.  I just need to find the spot, which I suspect is in
expr.c (gfc_reduce_init_expr)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[jvdelisle at gcc dot gnu dot org]

------- Comment #13 from jvdelisle at gcc dot gnu dot org  2009-11-28 01:46 -------
Created an attachment (id=19168)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19168&action=view)
Updated patch

This exploratory patch passes all regression tests.  I have also successfully
compiled and run the polyhedron benchmarks.

I have not tested higher order arrays to see if there is a compile time
improvement yet.  Feel free to test.  What I hope to eventually do is move the
expansion functions higher up the calling chain away from gfc_is_constant_expr.

Regardless, this is gives a fairly good improvement.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[jvdelisle at gcc dot gnu dot org]

------- Comment #14 from jvdelisle at gcc dot gnu dot org  2009-11-28 05:04 -------
I missed one regression from the patch in comment #13. Stay tuned.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[jvdelisle at gcc dot gnu dot org]

------- Comment #15 from jvdelisle at gcc dot gnu dot org  2009-11-28 15:10 -------
Created an attachment (id=19170)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19170&action=view)
Third time is a charm

This patch resolves the last remaining regression.  Removing the "didn't
reduce" error allows things to proceed to the exceeds maximum size error
message expected by initialization_20.f90.  It also triggers at the correct
limit.  I reworked one of the test conditions to assure that both
gfc_check_constructor_type and gfc_expand_constructor (expr) are executed.  I
was not sure that was strictly neccessary, but I was suspicious of that logic
that could eliminate one of the two in the OR.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #19161|0                           |1
        is obsolete|                            |
  Attachment #19168|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[jvdelisle at gcc dot gnu dot org]

------- Comment #16 from jvdelisle at gcc dot gnu dot org  2009-11-28 15:16 -------
With this simply modified case:

program sel
    implicit none
    integer,parameter              :: n=10
    integer                        :: i,j,k,l
    real,dimension(n*n*n*n) :: vect
    vect(:) = (/ ((((( (i+j+k+l+3)),i=1,n),j=1,n),k=1,n),l=1,n) /)
    print *, vect
end

Compilation time is reduced by 1/2 with the patch. Other more complex examples
need to be tested of course.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[dominiq at lps dot ens dot fr]

------- Comment #17 from dominiq at lps dot ens dot fr  2009-11-28 16:30 -------
With the patch in comment #15 (gfc, gfc_c without), I see the following for the
test

[macbook] f90/bug% cat pr19925_1_db.f90
INTEGER, PARAMETER :: N=100000
INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/)
INTEGER, PARAMETER :: M(N)=I(N:1:-1)
print *, I(1), M(1), I(N), M(N)
END

without (pr19925_1.f90)/with (pr19925_1_db.f90) the print line:

[macbook] f90/bug% time gfc_c pr19925_1.f90
pr19925_1.f90:3.36:

INTEGER, PARAMETER :: M(N)=I(N:1:-1)
                                    1
Error: Initialization expression didn't reduce (1)
368.554u 0.801s 6:09.49 99.9%   0+0k 0+5io 0pf+0w
[macbook] f90/bug% time gfc pr19925_1.f90
369.495u 0.629s 6:10.22 99.9%   0+0k 0+19io 0pf+0w
[macbook] f90/bug% a.out 
[macbook] f90/bug% time gfc_c pr19925_1_db.f90
pr19925_1_db.f90:3.36:

INTEGER, PARAMETER :: M(N)=I(N:1:-1)
                                    1
Error: Initialization expression didn't reduce (1)
367.576u 0.591s 6:08.25 99.9%   0+0k 0+5io 0pf+0w
[macbook] f90/bug% time gfc pr19925_1_db.f90
pr19925_1_db.f90:2.27:

INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/)
                           1
Error: The number of elements in the array constructor at (1) requires an
increase of the allowed 65535 upper limit.   See -fmax-array-constructor option
pr19925_1_db.f90: In function 'MAIN__':
pr19925_1_db.f90:4:0: internal compiler error: in
gfc_conv_array_constructor_expr, at fortran/trans-expr.c:3710
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
369.184u 0.620s 6:09.87 99.9%   0+0k 0+5io 0pf+0w


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[jvdelisle at gcc dot gnu dot org]

------- Comment #18 from jvdelisle at gcc dot gnu dot org  2009-11-28 17:14 -------
Created an attachment (id=19172)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19172&action=view)
Slightly modified charm

This version handles Dominique's test case in comment #17.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[jvdelisle at gcc dot gnu dot org]

------- Comment #19 from jvdelisle at gcc dot gnu dot org  2009-11-28 17:52 -------
The patch in comment #18 passes all regression tests as well.  I hope we are
honing in on this.  It does make me wonder why at this point the BT type is
unknown.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[jvdelisle at gcc dot gnu dot org]

------- Comment #20 from jvdelisle at gcc dot gnu dot org  2009-11-29 19:36 -------
Created an attachment (id=19180)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19180&action=view)
Hopefully final patch

This patch moves the number of elements patch up front so that the error is
given almost immediately. Previously, with one of Dominique's test cases, it
would take over 15 minutes on my machine here before one find's out there is a
problem.  I use gfc_fatal_error because compilation at that this early stage
continues on happily before quitting.  Can be very annoying for programs with
large array constructors.  Testing continues. 


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #19170|0                           |1
        is obsolete|                            |
  Attachment #19172|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[dominiq at lps dot ens dot fr]

------- Comment #21 from dominiq at lps dot ens dot fr  2009-11-29 22:10 -------
With the patch in comment #20, I get several new failures:

gcc/testsuite/gfortran.dg/actual_array_constructor_3.f90
pr20923 and friends
pr34554        "

IIRC when the constructors are used as initialization or in statements, they
are expanded at compile time when possible if the length is less than 2^16,
otherwise they are computed at run time. I think this behavior should be kept.
The only cases for which the fatal error should be triggered is for PARAMETERS
as in pr19925 that must be computed at compile time.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[jvdelisle at gcc dot gnu dot org]

------- Comment #22 from jvdelisle at gcc dot gnu dot org  2009-11-30 03:59 -------
Ok, if I back up one step and leave the error message in trans-array.c and use
gfc_fatal_error we get a usable patch.  One thing this is showing is that the
expansion is being done in the parsing/matching phase of compilation and also
in the resolution phase.  I do not yet understand why the ICE is triggered
after the error: (with the changes I have made elsewhere.)

          if (c->iterator)
            {
              /* Problems occur when we get something like
                 integer :: a(lots) = (/(i, i=1, lots)/)  */
              gfc_error_now ("The number of elements in the array constructor "
                              "at %L requires an increase of the allowed %d "
                              "upper limit.  See -fmax-array-constructor "
                              "option", &expr->where,
                              gfc_option.flag_max_array_constructor);
              return NULL_TREE;
            }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[jvdelisle at gcc dot gnu dot org]

------- Comment #23 from jvdelisle at gcc dot gnu dot org  2010-01-09 17:47 -------
Subject: Bug 20923

Author: jvdelisle
Date: Sat Jan  9 17:47:04 2010
New Revision: 155769

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155769
Log:
2010-01-09 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.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/array.c
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-array.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[jvdelisle at gcc dot gnu dot org]

------- Comment #24 from jvdelisle at gcc dot gnu dot org  2010-01-09 19:01 -------
Subject: Bug 20923

Author: jvdelisle
Date: Sat Jan  9 19:01:41 2010
New Revision: 155773

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155773
Log:
2010-01-09 Jerry DeLisle <jvdelisle@gcc.gnu.org>

        PR fortran/32489
        * gfortran.dg/array_constructor_33.f90: New test.

        PR fortran/20923
        Fix ChangeLog entry.

Added:
    trunk/gcc/testsuite/gfortran.dg/array_constructor_34.f90
Modified:
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/20923] gfortran slow for large array constructors

[jvdelisle at gcc dot gnu dot org]

------- Comment #25 from jvdelisle at gcc dot gnu dot org  2010-01-14 03:04 -------
Fixed on trunk.  New constructor code on fortran-exp will probably take a whole
new approach on this.

Closing.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923