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] |
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] |