[Gomp-discuss] "#pragma omp" and GCC

[Steven Bosscher]

Op di 04-02-2003, om 22:28 schreef Steven Bosscher:
> Op di 04-02-2003, om 18:44 schreef Diego Novillo:
> > On Tue, 04 Feb 2003, Biagio Lucini wrote:
> > 
> > > This syntax is (almost) shared by the pragmas
> > > 
> > > omp parallel
> > > omp parallel for
> > > omp parallel sections
> > > 
> > > Somehow simpler are the "omp sections" and "opm for", but just because
> > > they are "sub-pragmas" of "opm parallel". 
> > > 
> > Thanks.  It shouldn't be a huge deal.  Then again, I won't be the
> > one making those changes :)
> 
> The hardest part is making sure that whatever follows the pragma is
> legal.  You don't want to write your own 'for'-parser just for OpenMP,
> but OpenMP directives restrict the syntax of such statements.  There are
> similair examples.
> 
> I don't have a clue how this would have to be dealt with, and if no-one
> on this list does, I guess we'll have to ask on the gcc mailing list.  

Yuck, it's really not easy...

I made a crude implementation of the most simple C OMP pragmas to play
with, and I run in trouble all over when I need to interact with the
parser. Two examples:

a. A "section" directive must appear in the block of an "sections"
directive.
In the specification, they define "section-scope" as a set of "section"
directives followed by a "stuctured-blocks".  The set of sections is
enclosed by brackets.  I don't know how we could make sure that when we
see a "section" directive, we're inside a "section-scope".

b. All OpenMP pragmas put restrictions on syntax.
So, "parallel", "section", "sections", "single", "master", "critical",
and "atomic" all put restrictions on what can follow the directive.


The current GCC pragma mechanism only deals with oneliner pragmas that
do not put restrictions on the syntax of whatever follows the pragma
(right?).  The pragma's I see all deal with declarations (weak, poison,
redefine_extname, etc).  They work immediately on existing declarations,
and there's a "maybe_apply_*" callback function for the front ends
(called from c-decl.c) in case the pragma refers to a declaration that
has not yet been parsed.

The difference between statements and declarations is that the latter
can appear anywhere and still be affected by the pragma, whereas a
pragma working on a statement only applies to the first statement
following the pragma (at least for OpenMP this is the case), and *only*
if the syntax of that statement conforms to certain rules.  Otherwise
the pragma is malformed and should be discarded.

So we have two things that we need to figure out for the C front end:
1) A mechanism to transfer the information of the completely parsed omp
pragma to the C syntax tree.
2) A mechanism to check that the statement following the omp pragma
conforms to the OpenMP specs.


I think that for the sollution to 1) we can mimic the mechanism used for
other pragmas.  The idea is:
- parse the OpenMP directive and put it on a stack of pending
  directives if it is not malformed.
- parse the syntax as if there was no pragma.
- see if there is (are?) a pending OpenMP directive.  If so, call
  a callback function that takes the newly created piece of parse
  tree and see if the syntax conforms to the OpenMP specs.

I've looked at three strategies to figure out how/where to insert the
callback functions for OpenMP pragmas.

The first strategy is to add the pragmas as statements.  Conformance
checking would be postponed until just before or during lowering to
GENERIC.  *The* reason why I would like to avoid this, is that when
there are warnings or errors, they're issued out of order with other
errors/warnings that may have been detected during parsing.  OTOH you
could also say that we shouln't even try to lower to GENERIC if there
were errors, and warnings may not be that important.  Still I don't like
this one much.

The second strategy is to insert the callbacks in the relevant parts in
c-parse.in (compstmt, select_or_iter_stmt.  Still need to figure out
"atomic").  Maybe this is a good strategy because I think you'd need to
insert callbacks for every production in "stmt".  Bah.  Also, you'd need
to keep some kind of stack to track the nesting level of compound
statements, for example because all "section" directives must be at the
same nesting level.  I suppose some mechanism for that already exists in
the C front end, but I haven't found it yet.

The thirth method is to put a callback in c-semantics.c:add_stmt().  Now
you wouldn't have that many callbacks all over.  Just one over here will
do.  The problem of scope still remains.  An additional problem seems to
be that add_stmt() is not used consistently.  For example, I found this
in c-common.c:

---- 8< ----
  /* Begin an if-statement.  Returns a newly created IF_STMT if
     appropriate.

     Unlike the C++ front-end, we do not call add_stmt here; it is
     probably safe to do so, but I am not very familiar with this
     code so I am being extra careful not to change its behavior
     beyond what is strictly necessary for correctness.  */

  tree
  c_begin_if_stmt ()
  {
    tree r;
    r = build_stmt (IF_STMT, NULL_TREE, NULL_TREE, NULL_TREE);
    return r;
  }
---- 8< ----
(I'd like to see CVS blaim for this snippet to see who "I" is ;-)

We'd miss this IF_STMT with a callback in add_stmt().  I think we can
work around this if we're careful, but I think it might be a good idea
to try and make the front end use add_stmt() when possible.
(The one above is one of two such comments I found, but the "stmt"
production in c-parse.y has a few more statements that are not chained
to the parse tree with add_stmt()).


The sollution to 2) shouldn't be very hard.  The trouble is that what's
on the top of the stack of pending OpenMP directives could be many lines
away from the line were the pragma was seen, e.g.

#pragma sections blablabla
printf ("I'm not supposed to be here\n");
{
  do_cool_stuff_in_one_thread;
  #pragma section
  do_cool_stuff_in_another thread;
}

This is illegal because the printf is not allowed there (must be a '{'
after a "sections" directive).

Is this something we could check for using the stmt_count from
c-parse.in? Right now it's static but it could be moved to, say,
c-semantics.c.  Other suggestions?

Enough for today.

Greetz
Steven