[cfe-dev] about OpenACC support, Preprocessor and pragma handlers in general

Maroudas Manolis kapamaroo at gmail.com
Mon Nov 26 06:52:31 PST 2012


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 

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 
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 

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


Maroudas Manolis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pragma-handlers-extension.patch
Type: text/x-patch
Size: 4381 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121126/b5294434/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openacc-preprocessor-handler.h
Type: text/x-chdr
Size: 317 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121126/b5294434/attachment.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openacc-preprocessor-handler.cpp
Type: text/x-c++src
Size: 767 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121126/b5294434/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openacc-parser-handler.cpp
Type: text/x-c++src
Size: 2200 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121126/b5294434/attachment-0001.cpp>

More information about the cfe-dev mailing list