[Bug fortran/32382] missed optimization in internal read
--- 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=gccview=revrev=156755 Log: 2010-02-14 Jerry DeLisle jvdeli...@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
--- 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 changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
[Bug fortran/32382] missed optimization in internal read
--- 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=19856action=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: real0m2.100s user0m0.777s sys 0m0.009s to: real0m0.013s user0m0.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
--- 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
--- 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=14299action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
[Bug fortran/32382] missed optimization in internal read
--- 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
--- 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
--- 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
--- 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 = 100)
{
while (1)
{
{
logical4 D.1371;
_gfortran_transfer_integer (dt_parm.2,
intvalues[(int8) i + -1], 4);
L.4:;
D.1371 = i == 100;
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_20;
case 2:;
goto __label_20;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
[Bug fortran/32382] missed optimization in internal read
--- 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|-00-00 00:00:00 |2007-06-17 20:47:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
