about OpenACC support, Preprocessor and pragma handlers in general

Hello,

I am quite new in clang and I am intrested in OpenACC support.
My goal is to write a tool to transform C code with OpenACC directives to OpenCL code, so I am just focusing at the parsing
phase and AST creation for now.

I keep an eye in a thread about OpenMP "OpenMP support in CLANG: A proposal" as both cases are quite similar. I have a concern
about the structure of my implementation so far.

As far as I can tell, any #pragma directives must be handled by the Preprocessor (that's where they belong). But in the case of
OpenMP and OpenACC directives I think a Parser handler is more appropriate, because we need some semantic information about
their clauses not available in the Preprocessor.

I will give a random example in OpenMP of what I mean, as OpenACC may not be so popular yet!

#pragma omp parallel private(tid, i) shared(n,A,B,C,D)
  {
    tid = omp_get_thread_num();
    if (tid == 0)
      nthreads = omp_get_num_threads();

    #pragma omp for nowait
    for (i=0; i<n; i++) {
      B[i] = 2.0*A[i];
    }

    #pragma omp for
    for (i=0; i<n; i++) {
      D[i] = 1.0/C[i];
    }

  }

In the above code the first OpenMP directive has a 'shared' clause with a parameter list of elements n,A,B,C,D.

The Preprocessor cannot say whether these identifiers are actually declared previously as variables or not, but the Parser can
with help from Sema actions and produce better diagnostics. Also already implemented methods from Parser can be used to parse
this clause e.g. a modified version of ParseExpressionList(). The OpenACC specification has almost identical structure for its
clauses.

As I found, at the end of a directive in general, the Preprocessor returns the eod token to Parser. Is this the only visible
change in Preprocessors behavior from the Parser's perspective?

In my code I split the parsing in a Preprocessor (PP) Handler and a Parser Handler.
1. The PP Handler recognizes the start point of a OpenACC directive ('#' 'pragma' 'acc') and replaces it with an annotated token
(tok::annot_pragma_acc).
2. The Parser Handler consumes the body of the directive until eod using the available semantic information from Sema.

I have made a patch (attached) that lets these types of "Extension" pragma directives to be handled by the Parser instead of the
Preprocessor. The patch actually adds some bits in the PragmaHandler class in "include/clang/Lex/Pragma.h", hopefully not too
much!

I also send my initial implementation of the Preprocessor and Parser Handlers (just the intresting parts).

I don't know if this is a right approach so please take a look at it and let me know.

for more information about OpenACC
http://www.openacc-standard.org/

Thanks,

Maroudas Manolis

pragma-handlers-extension.patch (4.28 KB)

openacc-preprocessor-handler.h (317 Bytes)

openacc-preprocessor-handler.cpp (767 Bytes)

openacc-parser-handler.cpp (2.15 KB)

What's the motivation for this work? Is it that you lack access to the desired target backend/runtime or you're doing research and just short-cut/easy/don't care about production robustness.

What's the motivation for this work? Is it that you lack access to the
desired target backend/runtime or you're doing research and just
short-cut/easy/don't care about production robustness.

We are currently doing some research in my University on Heterogeneous Computing and we work on OpenCL. I am interested in
developing a tool which gives access to our tools without requiring the programmer to mess with OpenCL directly, letting them to
use higher level structures to express the parallelization in a program (exactly what OpenACC tries to achieve).

As I am an undergraduate student yet, I am doing this project mainly for research, yes :slight_smile:
Also, I would like to get involved into clang's development.

I don't want to pee on anyone's party, but have you considered at all
how difficult it will be to
1) Validate the results
2) Debug this when things go sideways
3) Will it ever need to play nice with MPI in a clustered environment
4) Performance tuning or even profiling

As our research continues we are working on them too! :slight_smile:

PathScale has OpenACC/AMP/OpenMP/CUDA support in clang and are pretty
liberal with research groups that would want private access. Email me
privately if interested.

I am particularly interested in compiler technologies and code transformation tools. I will take a look at Pathscale's tools on
my free time. A quick search gives me the following two links:

https://github.com/pathscale
https://github.com/path64/compiler

Thank you very much,

Maroudas Manolis