[Gomp-discuss] Implementing OpenMP pragmas for the C front end

[Steven Bosscher]

Hi,

Over the past few days we've had an interesting discussion in the GOMP
project mailing list about implementing the OpenMP directives and
constructs (#pragma omp) in the C front end.  

The issue is that the OpenMP pragmas are quite different from the
pragmas GCC currently supports.

GCC right now only has pragmas that do not put restrictions on the
language elements surrounding the pragmas.  AFAICT most pragmas have
their effect over the whole translation unit.

Pragmas are registered in cpplib with a handler that is called from
cpplib.  So the lexer and parser never see the pragmas. This makes it a
bit difficult to have elaborate interaction between the parser and the
pragma handlers.  There are additional callbacks for most pragmas from
c-decl (the maybe_apply_{weak,renaming_pragma} functions) because the
compiler may encounted symbols that are affected by those pragmas long
after the pragma itself was handled.

In OpenMP, the pragmas are more like grammar productions.  Certain
pragmas can only be followed or by a compound statement, some other
pragmas can only appear inside a compound.  Some constructs need
information about scope and/or about how deep they're nested.

In fact, the OpenMP specifications present the OpenMP pragmas as grammar
extensions for C/C++!

To give you an idea of how C syntax and OpenMP pragmas (don't) always go
together, here's an example from the OpenMP 2.0 specs for C/C++),
----------
/* ERROR - The flush directive cannot be the immediate
 * substatement of an if statement. */
if (x!=0)
  #pragma omp flush (x)
...

/* OK - The flush directive is enclosed in a * compound statement */
if (x!=0)
  {
    #pragma omp flush (x)
  }
----------

Another example: In a sections construct, all section directives must be
in the lexical extend of a sections construct:
----------
#pragma omp sections [clause[[,] clause] ...] new-line
  {
    [#pragma omp section new-line]
    structured-block

    #pragma omp section new-line
    structured-block
    ...
  }

/* ERROR - The section directive is not in the lexical extend of the
 * sections construct.  */
#pragma omp section new-line
structured-block 
----------


Actually parsing the pragmas is of course quite easy.  Making sure they
appear in a legal context is not, so that's what the discussion on the
GOMP list focussed on.

We considered callbacks and I've tried to play with that a bit.  It
seems we would at least need callbacks from start_decl() and add_stmt()
and we need a way to keep track of the current binding level.  I have
not yet found a way to enforce that the barrier and flush directives
only appear where they're allowed to; haven't looked into that much yet,
really.

(For those of you who're interested, here's the piece of the grammar
extensions from the OpenMP specs for the flush and barrier directives:

block-item:
          declaration
        | statement
        | openmp-directive
        ;

openmp-directive:
          barrier-directive
        | flush-directive
        ;

The complete "grammar extension" is 6 pages in the OpenMP 2.0 specs.)


But I don't like all the callbacks much.  It may clutter the code for
people who don't care about OpenMP, and it is more prone to errors than
I would like (it's so easy to overlook something in the parser...). 
Obviously, we would like to keep the changes to existing front end files
small.

So I would like to ask for some input from people who know the C front
end better than most of us un the GOMP project do.  To give you an idea
of the questions we're trying to find answers to, here are two of them:

1) How can we make sure that the OpenMP pragmas that require so are
always immediately followed by a compound statement?  The current plan
is to hook {push/pop}level and see if a COMPOUND_STMT is the first thing
following the #pragma.

2) How can we make sure all "section" directives are in the lexical
extend of a "sections" construct?  No clue of how to do that.

Other suggestions/ideas/insights are very welcome too, of course ;-)

We have already looked at the Open64 C/C++ front ends, which are just
the "GCC 2.96" experimental front ends.  Unfortunately it looks like
they haven't implemented it there yet.

Greetz
Steven