This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp] parse OpenMP directives
On Wed, 13 Oct 2004, Paolo Bonzini wrote:
> > Indeed, I strongly recommend doing something that works to get OpenMP
> > implemented - even if it does involve duplicate parsing implementations or
> > other duplication or designs that might not be ideal were you writing a
> > whole compiler collection from scratch - and avoiding false dependencies on
> > large changes to or replacements of other parts of the compiler.
>
> Would it be fine to write a recursive descent parser used only for OpenMP
> code, and then extend it to handle arbitrary translation units?
Parsing expressions effectively in GNU C involves parsing most of the
language (consider statement expressions, and nested functions within
them, and that even standard C allows structs to be defined within
casts/sizeof). Your one sentence description is too short to be a
properly assessable design (besides which some analysis of benefits and
requirements, and of what the minimal incremental components of the change
are, would be needed). What could be done along the lines you suggest is
a recursive descent parser that for C parses expressions minimally by just
matching () [] {}, then reinjects a modified token sequence (with special
magic OpenMP tokens) handled by the Bison grammar; and that grammar then
calls the functions to build up the datastructures for the OpenMP
constructs, while for C++ the parser can call expression-parsing functions
directly.
For parser replacement I'd look for an analysis along the following lines,
but substantially fleshed out:
Benefits:
* Helps implement various parts of OpenMP fully.
* Compile-time performance improvements. (This is probable; there have
been statistics showing many cache misses in yyparse; but there should be
a proper analysis of why and other ways of avoiding them.)
* Better error recovery and more accurate diagnostic location.
* ....
Requirements:
* Provides recursive-descent parsing functions suitable for calling from
OpenMP functions.
* Performance no worse than existing code on .i files of cc1, preferably
better.
* No testsuite regressions; changes to precise line of diagnostics or to
messages after parse errors are permitted.
* Handles an identical C dialect to existing parser, with the same
diagnostics but maybe in different locations and identical generated code
except maybe for line numbers in debug info; diagnostics for syntactically
incorrect programs may differ; existing bugs are to be fixed separately,
and diagnostic improvements are to be made separately.
* ....
Alternatives:
* Could the C++ parser be adapted? (The principles of minimal incremental
changes mean that if the aim is to replace a parser then larger
replacements such as "merge C and C++ front ends" don't need considering
as alternatives, but a parser replacement could be considered as one
incremental change towards such a merge, depending on the design adopted.)
* ....
Minimality:
* Parser actions and code in c-parse.in can move to separate files
separately from a parser replacement, and so should move separately.
Otherwise replacing a parser with minimal changes to other files is the
minimal change.
Testing:
* Tests will be added to the testsuite in advance to cover any and all
parts of the existing parser that are not currently covered (both C and
ObjC).
* All new code other than asserts and aborts will have 100% testsuite
coverage.
* Specified performance tests to be done.
Documentation:
* There should be no user-visible changes needing documenting although a
note in the release notes would be appropriate. However, documentation
referring to parser source files would need updating.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
jsm@polyomino.org.uk (personal mail)
joseph@codesourcery.com (CodeSourcery mail)
jsm28@gcc.gnu.org (Bugzilla assignments and CCs)