[FORTRAN PATCH] Reduce gfc_match_strings usage (part 2)
Sun Mar 11 17:13:00 GMT 2007
On Sun, March 11, 2007 9:02 am, Tobias SchlÃ¼ter wrote:
> As an aside to all the discussion about the implementation strategy for
> the matchers, I'd like to point out that standard Fortran has a .xor.
> operator, which is called .neqv.. Unless you intend to give .xor. a
> different precedence, its implementation should be trivial (unless I
> underestimate the difficulties a collision with a user-defined operator
> could bring), so I'm wondering what kind of difficulties are you seeing?
Exactly, the implementation should be almost trivial with ".xor." being
treated as a synonym for ".neqv.". The major difficulty I envisaged was
in the parser. Depending upon the applicable standard, ".xor." should
either be recognized as an intrinsic silently, be matched as an intrinsic
and issue a diagnostic warning or not be recognized and fall through to
being treated as a general identifier (without type checking etc...)
Unfortunately, the current structure of "gfc_match_strings" in addition to
being inefficient, doesn't easily allow conditional keyword matching.
With the proposed scheme, supporting ".xor." might be as simple as
if (gfc_next_char () == 'o'
&& gfc_next_char () == 'r'
&& gfc_next_char () == '.')
/* Matched ".xor.". */
if (gfc_notify_std (GFC_STD_GNU, "...") == SUCCESS)
*result = INTRINSIC_NEQV;
Or alternatively, we could add a new INTRINSIC_XOR, to allow error
messages and modules to display ".xor." instead or ".neqv.", and treat
it as a synonym for INTRINSIC_NEQV everywhere.
Whilst in theory, it is possible to add a wrapper around the current
gfc_match_strings, remembering the state before, checking whether it
returns INTRINSIC_XOR, and then deciding to either restrore
gfc_current_locus and return MATCH_NO, or accept the ".xor." and transform
it in INTRINSIC_NEQV, this overhead would make the current implementation
even less efficient, and inserts more code to the common/critical path.
As confirmed by FX, gfc_match_strings is already the hotest function in
the gfortran front-end.
More information about the Gcc-patches