ompparser: A Standalone and Unified OpenMP Parser

I would like to bring to your attention the ompparser we developed. https://github.com/passlab/ompparser. We have a IWOMP’19 paper for it and the presentation (http://parallel.auckland.ac.nz/iwomp2019/slides_ompparser.pdf) gives you a quick summary of it.

Comments are most welcome.

Hi,

very interesting development, thanks for sharing it.

Did you consider a more “push-like” approach along with callbacks to decouple and ease integration with existing parsers?

This way an existing base language parser (say, hypothetically, clang or flang) can push essential tokens that correspond to purely the directive syntax (parallel, for, if, nowait, etc.) and then the OpenMP parser could tell the base language parser “now parse this part of the language you know about”.

For instance, parsing a clause like “num_threads(1+2)”. clang could push tokens “num_threads”, “(” and then the OpenMP parser (assuming we are deterministic enough!) would let know clang “now parse an expression” which would consume 1+2 and pass the expression (possibly opaquely) to the OpenMP parser. Lastly clang would push “)” and a full num_threads has just been recognized.

To communicate the parser that a part of the OpenMP syntax has been recognized (in this case a num_threads clause) I imagine either a callback could be used or perhaps the push token function could return a result (this is less clear to me, to be honest).

One limitation of this approach would be that the base language still has to know some OpenMP syntax bits like “a[lower:size]” for C/C++ depend clauses. Declare reduction directive also includes a few special identifiers (like omp_priv) that the base language parser may need to be told about.

Kind regards,

Missatge de Yonghong Yan via Openmp-dev <openmp-dev@lists.llvm.org> del dia dc., 18 de set. 2019 a les 1:26:

Hi Roger,

Per my understanding, by doing the approach you described, the base language compiler would need to know the OpenMP syntax, and choose what it needs the parser to process. It would be hard to make the “parser” standalone since it depends on what base compilers can do for openmp parsing.

Right now, ompparser processes a whole line of an omp construct. The callback mechanism we have in mind, but have not yet fully experiment, is to let base compiler passes to the ompparser a callback that can parse a single C/C++/Fortran expression and identifier. For each expression and identifier that ompparser identifies and separates, the callback would produce an opaque object associated with string-representation of the expression/identifier. All the opaque objects for a clause, e.g. “private (a, b, c)”, can be iterated using an iterator provided by the ompparser. In this approach, two scannings are needed, one by ompparser to tokenize it and another by compiler to parse it.

Letting the compiler callback to process a list of identifiers/expressions/array section/range would work as well as long as the ompparser tells the compiler the stopping character, e.g. “)”. This would need only one scan/parse by the compiler.

Yonghong

Hi,

thanks for the detailed explanation.

Kind regards,

Missatge de Yonghong Yan <yanyh15@gmail.com> del dia dl., 7 d’oct. 2019 a les 14:01: