This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] Restructure intrinsic operator parsing


The following patch reorganizes the way that intrinsic operators, such as
"==", "<=" and ".not." are parsed by the gfortran front-end.  Instead of a
table-driven implementation using gfc_match_strings (whose running time is
linear in the number of strings being matched), we switch to an efficient
inline implementation (whose running time is independent of the number of
strings to be matched).

Although gfc_match_strings shows up at the top of a profile of the
gfortran front-end, from my limited experiments, improving the efficiency
of operator parsing has only a very small, reproduceable but probably
statistically insignificant, reduction in compile-time using -O0
-fsyntax-only.  This may be dependent on the source being compiled, and
others may see a more significant benefit.

Fortunately, the major motivation for this patch was not purely/orginally
compile-time; the new implementation allows us to easily add conditional
processing of intrinsic operators, for example as GNU extensions.  Patch
to follow.


The patch below has been tested on x86_64-unknown-linux-gnu, with a full
"make bootstrap", including gfortran, and regression tested with a
top-level "make -k check" with no new failures.

Ok for mainline?


2007-08-21  Roger Sayle  <roger@eyesopen.com>

        * match.c (intrinsic_operators): Delete.
        (gfc_match_intrinsic_op): Rewrite matcher to avoid calling
        gfc_match_strings.

Roger
--

Attachment: patch.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]