[Bug libfortran/38199] missed optimization: I/O performance

["manfred99 at gmx dot ch" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #16 from Manfred Schwarb <manfred99 at gmx dot ch> 2012-03-19 09:42:29 UTC ---
Thanks, Janne, for your patch. It does not help very much, though.
[ As expected, as the reading part is the bottleneck ]

My current timings of the second test case:
g77: 12.41s
4.3: 14.60s
4.5: 18.55s
4.7: 17.21s
4.8: 16.80s (inkl. Janne's patch)
len_trim variant, 4.3: 0.92s
len_trim variant, 4.8: 0.24s

That's still a factor 70 (sic!) away from the optimized variant.
And we are still slower than GCC 4.3 and g77.

The len_trim variant improved a lot, probably due
to Janne's patch.


Now, the interesting thing is:
I tried to figure out at which point the len_trim variant
is slower due to the len_trim overhead.
On my box, this point does not exist, i.e. the len_trim
variant is always faster!

I.e. even for
      character buffer*10

the len_trim variant is faster!

Which suggests that a brute-force approach to unconditionally 
issue a "len_trim" in the relevant gfortran reading routine 
would always be a win!