[Openmp-dev] ompparser: A Standalone and Unified OpenMP Parser

[Roger Ferrer Ibáñez via Openmp-dev]

Hi,

thanks for the detailed explanation.

Kind regards,

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

> 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
>
> On Fri, Sep 27, 2019 at 5:00 PM Roger Ferrer Ibáñez <rofirrim at gmail.com>
> wrote:
>
>> 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 at lists.llvm.org> del
>> dia dc., 18 de set. 2019 a les 1:26:
>>
>>> 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.
>>>
>>> Yonghong Yan
>>> Associate Professor
>>> Department of Computer Science
>>> University of North Carolina at Charlotte
>>> Office: 410F Woodward
>>> Phone: 704-687-8546
>>> Email: yyan7 at uncc.edu
>>> https://passlab.github.io/yanyh/
>>> _______________________________________________
>>> Openmp-dev mailing list
>>> Openmp-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>>>
>>
>>
>> --
>> Roger Ferrer Ibáñez
>>
>

-- 
Roger Ferrer Ibáñez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20191007/d8925d7f/attachment.html>