[Bug fortran/32382] New: missed optimization in internal read

[Bug fortran/32382] New: missed optimization in internal read

[manfred99 at gmx dot ch]

This is a followup to BUG 32257.
Above Bug has been resolved as invalid, but how comes that
the loop variable i has the value 101 at the end of the read?

consider
C234567
      program internalread
      implicit none
      integer m
CC      parameter(m=100)
      parameter(m=1000000)
      character value*10
      integer i,j,intvalues(m)

      DO j=1,100
        write(value,'(i3,a5)') j," 5 69"
        write(*,*) value
        read(value,*,end=20,err=20) (intvalues(i),i=1,m)
20      write(*,*) j
      ENDDO
      end program internalread

(There is no access to i after the loop, so this program 
should be valid)

m=100:
gfortran needs 0.003s
g77 needs 0.002s

m=1000000:
gfortran needs 0.8s
g77 needs 0.002s

So gfortran loops to its bitter end, although it could 
shortcut the loop. g77 seems to exit the loop at i=3, as
BUG 32257 shows as well.


-- 
           Summary: missed optimization in internal read
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: manfred99 at gmx dot ch


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

[Bug fortran/32382] missed optimization in internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #1 from jvdelisle at gcc dot gnu dot org  2007-06-17 20:47 -------
I will explore this a bit.  Its interesting.  


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-06-17 20:47:51
               date|                            |


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

[Bug fortran/32382] missed optimization in internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #2 from jvdelisle at gcc dot gnu dot org  2007-06-23 03:13 -------
This problem is frontend related.  We are building the switch case that tests
for the error conditions outside the loop that is constructed to do the scaler
transfers.  Thus:

              i = 1;
              if (i <= 1000000)
                {
                  while (1)
                    {
                      {
                        logical4 D.1371;

                        _gfortran_transfer_integer (&dt_parm.2,
&intvalues[(int8) i + -1], 4);
                        L.4:;
                        D.1371 = i == 1000000;
                        i = i + 1;
                        if (D.1371) goto L.5;
                      }
                    }
                }
              L.5:;
              _gfortran_st_read_done (&dt_parm.2);
              switch (dt_parm.2.common.flags & 3)
                {
                  case 1:;
                  goto __label_000020;
                  case 2:;
                  goto __label_000020;
                }


-- 


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

[Bug fortran/32382] missed optimization in internal read

[manfred99 at gmx dot ch]

------- Comment #3 from manfred99 at gmx dot ch  2007-09-02 11:53 -------
Jerry, any news on this?

I have seen this pattern many times in legacy fortran77 code,
and the code authors seem to assume that ridiculously large loop
stop values do not compromize performance.

After all, in fortran77 you have to do something like this if you don't
know the dimension to the data to read.

Interestingly, ifort seems to have changed their mind,
as ifort 8.1 seems to loop till the end (see comp.lang.fortran 
link in BUG 32257), whereas ifort 9.0 stops at value 4, like g77.
And, as mentioned in BUG 32257, the compiler is free to choose.


-- 


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

[Bug fortran/32382] missed optimization in internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #4 from jvdelisle at gcc dot gnu dot org  2007-09-02 16:08 -------
Well, it has not been on my top burner.  Looking at -fdump-tree-original the
problem can be seen easily.  Fixing is not so straight forward.  This will
probably not happen until 4.4.


-- 


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

[Bug fortran/32382] missed optimization in internal read

[manfred99 at gmx dot ch]

------- Comment #5 from manfred99 at gmx dot ch  2007-10-05 09:37 -------
Created an attachment (id=14299)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14299&action=view)
test case


-- 


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

[Bug fortran/32382] missed optimization in internal read

[manfred99 at gmx dot ch]

------- Comment #6 from manfred99 at gmx dot ch  2007-10-05 09:38 -------
(From update of attachment 14299)
sorry, for wrong bug


-- 

manfred99 at gmx dot ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #14299|0                           |1
        is obsolete|                            |


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

[Bug fortran/32382] missed optimization in internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #7 from jvdelisle at gcc dot gnu dot org  2009-09-13 14:30 -------
I will not have time to work on this one. Un-assigning.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug fortran/32382] missed optimization in internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-02-13 06:17 -------
Created an attachment (id=19856)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19856&action=view)
Prelinary patch to fix this

The attached patch is preliminary.  It borrows the existing gfc_trans_do code
and creates special versions just for implied do loops in I/O statements.  This
adds a simple test to exit the loop on iostat of END, EOR, or EOF.  The
overhead is light relative to the I/O.

Speeds up the testcase from:

real    0m2.100s
user    0m0.777s
sys     0m0.009s

to:

real    0m0.013s
user    0m0.000s
sys     0m0.004s

I plan to refactor the code to simplify it all.  This first patch is just proof
of principle and does pass regression tests.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


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

[Bug fortran/32382] missed optimization in internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #9 from jvdelisle at gcc dot gnu dot org  2010-02-14 08:29 -------
Subject: Bug 32382

Author: jvdelisle
Date: Sun Feb 14 08:28:50 2010
New Revision: 156755

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

        PR fortran/32382
        * trans-stmt.h: Add prototype for gfc_trans_code_cond. Add tree cond to
        gfc_trans_do prototype.
        * trans-stmt.c (gfc_trans_simple_do): Add optional argument to pass in
        a loop exit condition.  If exit condition is given, build the loop exit
        code, checking IO results of implied do loops in READ and WRITE.
        (gfc_trans_do): Likewise.
        * trans.c (trans_code): New static work function, previously
        gfc_trans_code. Passes exit condition to gfc_trans_do.
        (gfc_trans_code): Calls trans_code with NULL_TREE condition.
        (gfc_trans_code_cond): Calls trans_code with loop exit condition.
        * trans-io.c (build_dt): Build an exit condition to allow checking IO
        result status bits in the dtparm structure. Use this condition in call
        to gfc_trans_code_cond.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-io.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans-stmt.h
    trunk/gcc/fortran/trans.c


-- 


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

[Bug fortran/32382] missed optimization in internal read

[jvdelisle at gcc dot gnu dot org]

------- Comment #10 from jvdelisle at gcc dot gnu dot org  2010-02-14 08:33 -------
Fixed on trunk.


-- 

jvdelisle at gcc dot gnu dot org changed:

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


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

[Bug fortran/32382] missed optimization in internal read

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.5.0


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