* [Bug fortran/32382] missed optimization in internal read
2007-06-17 20:29 [Bug fortran/32382] New: missed optimization in internal read manfred99 at gmx dot ch
@ 2007-06-17 20:48 ` jvdelisle at gcc dot gnu dot org
2007-06-23 3:13 ` jvdelisle at gcc dot gnu dot org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2007-06-17 20:48 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/32382] missed optimization in internal read
2007-06-17 20:29 [Bug fortran/32382] New: missed optimization in internal read manfred99 at gmx dot ch
2007-06-17 20:48 ` [Bug fortran/32382] " jvdelisle at gcc dot gnu dot org
@ 2007-06-23 3:13 ` jvdelisle at gcc dot gnu dot org
2007-09-02 11:53 ` manfred99 at gmx dot ch
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2007-06-23 3:13 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/32382] missed optimization in internal read
2007-06-17 20:29 [Bug fortran/32382] New: missed optimization in internal read manfred99 at gmx dot ch
2007-06-17 20:48 ` [Bug fortran/32382] " jvdelisle at gcc dot gnu dot org
2007-06-23 3:13 ` jvdelisle at gcc dot gnu dot org
@ 2007-09-02 11:53 ` manfred99 at gmx dot ch
2007-09-02 16:08 ` jvdelisle at gcc dot gnu dot org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: manfred99 at gmx dot ch @ 2007-09-02 11:53 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/32382] missed optimization in internal read
2007-06-17 20:29 [Bug fortran/32382] New: missed optimization in internal read manfred99 at gmx dot ch
` (2 preceding siblings ...)
2007-09-02 11:53 ` manfred99 at gmx dot ch
@ 2007-09-02 16:08 ` jvdelisle at gcc dot gnu dot org
2007-10-05 9:37 ` manfred99 at gmx dot ch
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2007-09-02 16:08 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/32382] missed optimization in internal read
2007-06-17 20:29 [Bug fortran/32382] New: missed optimization in internal read manfred99 at gmx dot ch
` (3 preceding siblings ...)
2007-09-02 16:08 ` jvdelisle at gcc dot gnu dot org
@ 2007-10-05 9:37 ` manfred99 at gmx dot ch
2007-10-05 9:38 ` manfred99 at gmx dot ch
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: manfred99 at gmx dot ch @ 2007-10-05 9:37 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/32382] missed optimization in internal read
2007-06-17 20:29 [Bug fortran/32382] New: missed optimization in internal read manfred99 at gmx dot ch
` (4 preceding siblings ...)
2007-10-05 9:37 ` manfred99 at gmx dot ch
@ 2007-10-05 9:38 ` manfred99 at gmx dot ch
2009-09-13 14:30 ` jvdelisle at gcc dot gnu dot org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: manfred99 at gmx dot ch @ 2007-10-05 9:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/32382] missed optimization in internal read
2007-06-17 20:29 [Bug fortran/32382] New: missed optimization in internal read manfred99 at gmx dot ch
` (5 preceding siblings ...)
2007-10-05 9:38 ` manfred99 at gmx dot ch
@ 2009-09-13 14:30 ` jvdelisle at gcc dot gnu dot org
2010-02-13 6:17 ` jvdelisle at gcc dot gnu dot org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2009-09-13 14:30 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/32382] missed optimization in internal read
2007-06-17 20:29 [Bug fortran/32382] New: missed optimization in internal read manfred99 at gmx dot ch
` (6 preceding siblings ...)
2009-09-13 14:30 ` jvdelisle at gcc dot gnu dot org
@ 2010-02-13 6:17 ` jvdelisle at gcc dot gnu dot org
2010-02-14 8:29 ` jvdelisle at gcc dot gnu dot org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2010-02-13 6:17 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/32382] missed optimization in internal read
2007-06-17 20:29 [Bug fortran/32382] New: missed optimization in internal read manfred99 at gmx dot ch
` (7 preceding siblings ...)
2010-02-13 6:17 ` jvdelisle at gcc dot gnu dot org
@ 2010-02-14 8:29 ` jvdelisle at gcc dot gnu dot org
2010-02-14 8:33 ` jvdelisle at gcc dot gnu dot org
2010-02-14 15:02 ` hjl dot tools at gmail dot com
10 siblings, 0 replies; 12+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2010-02-14 8:29 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/32382] missed optimization in internal read
2007-06-17 20:29 [Bug fortran/32382] New: missed optimization in internal read manfred99 at gmx dot ch
` (8 preceding siblings ...)
2010-02-14 8:29 ` jvdelisle at gcc dot gnu dot org
@ 2010-02-14 8:33 ` jvdelisle at gcc dot gnu dot org
2010-02-14 15:02 ` hjl dot tools at gmail dot com
10 siblings, 0 replies; 12+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2010-02-14 8:33 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/32382] missed optimization in internal read
2007-06-17 20:29 [Bug fortran/32382] New: missed optimization in internal read manfred99 at gmx dot ch
` (9 preceding siblings ...)
2010-02-14 8:33 ` jvdelisle at gcc dot gnu dot org
@ 2010-02-14 15:02 ` hjl dot tools at gmail dot com
10 siblings, 0 replies; 12+ messages in thread
From: hjl dot tools at gmail dot com @ 2010-02-14 15:02 UTC (permalink / raw)
To: gcc-bugs
--
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
^ permalink raw reply [flat|nested] 12+ messages in thread