[Patch, Fortran] Experimental LEN_TRIM and TRIM patch

[Daniel Kraft]

Slightly improved patch and ChangeLog.

Daniel Kraft wrote:
> Hi,
> 
> here's an experimental patch to tune the LEN_TRIM and TRIM intrinsics. 
> In my own experience, I usually use TRIM (or LEN_TRIM) in combination 
> with strings allocated too large (because no dynamic length is 
> possible), so that there are usually lots of blanks at the end.
> 
> In this case (and for KIND=1 strings), instead of checking each and 
> every character if it is a blank, we can check them in chunks of 4 (or 
> 8) by comparing them as unsigned long integers.  That's what the patch 
> does, as well as add a test-case and re-use LEN_TRIM for TRIM instead of 
> duplicating the code there.
> 
> For the attached (extreme) test-case, the patch really gives nearly 4x 
> speed-up as expected for a best case; if the full string length is only 
> marginally larger than the trimmed one (like one trailing blank), the 
> patch slows down up to a factor of 2.  But as soon as there are 4-5 
> trailing blanks, the new version is faster.
> 
> Comments welcome!
> 
> I guess there are configure-set macros telling me if unsigned long is 4 
> or 8 bytes on the machine, so we can make the blank_long initialization 
> work on 64-bit, too...
> 
> Yours,
> Daniel
> 
> PS: BTW, while gfortran does not complain about CHARACTER(LEN=0) (don't 
> know if this is legal), for LEN=-1 one gets "Warning: CHARACTER variable 
> has *zero* length" which sounds quite a little confusing.
> 


-- 
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.diff
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20090212/b0b0b757/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.changelog
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20090212/b0b0b757/attachment-0001.ksh>