[cfe-dev] [RFC] OpenMP Support in Clang

[Douglas Gregor]

On Dec 27, 2012, at 4:41 AM, Alexey Bataev <a.bataev at gmx.com> wrote:

> Chandler,
> Sorry, my bad. See document in attach.

Some comments on the design document...

> General approach of parsing these directives is to use standard 
> pragma parsing harness. This invlolves implementation of ``PragmaHandler``-based

Typo "invlolves".

> class for all OpenMP pragmas or several PragmaHandlers for each particular
> pragma. Then each pragma, generally processed by ``Preprocessor``, should be turned
> into some particular statement-like construct (using
> ``Preprocessor::EnterTokenStream``), which then should be parsed in ``Parser``'s
> context.

Okay, that's the right approach. PragmaNamespace makes it fairly easy to have separate handlers for the various omp pragmas.

> This construct may represent some custom construct or could be
> transformed into some standard language construct. Olaf Krzikalla made `a proposal
> <http://clang-developers.42468.n3.nabble.com/OpenMP-support-in-CLANG-A-proposal-td4027258.html>`_
> to handle OpenMP constructs as attributes. So, we can try to translate OpenMP 
> pragmas into some form of GCC or C++11 attributes and use standard approach to
> parse these attributes. However, it requires at least two parsing passes,
> with first one transforming pragmas into attributes and second one translating
> attributes and verifying their semantic correctness. Thus, it seems that a
> better solution would be to introduce new annotation token for OpenMP pragmas
> and custom parsing procedures for translating OpenMP pragmas into some special
> new Stmts.

I agree that attributes is not the best way to go. The parser can parse the OpenMP pragma into a reasonable AST for that pragma. That AST goes to the normal statement parsing (e.g., an OpenMP parallel directive gets parsed and passed to the "for" statement parser), and gets carried along to semantic analysis. As part of type-checking the for loop, we'll check the OpenMP constraints.

I think separate statements makes sense, but it depends somewhat on how different they'll actually be and how many there are. Do you have a good sense of which statements we'll need?

> This approach allows separation of subsequent CodeGen stage for
> OpenMP Stmts from CodeGen stage for standard statements, while handling OpenMP
> pragmas as attributes requires rework of CodeGen procedures for almost all
> statements -- in order to handle these new OpenMP specific attributes.

Perhaps. I think it depends a bit on how function outlining is handled. In particular, I could certainly imagine that Sema is involved in outlining, e.g., by keeping track of which variables are captured (which it knows how to do for lambdas/blocks) and having an explicit outlined statement that specifies its captures. If that's the case, an OpenMP parallel for (for example), could be a ForStmt whose body is an outlined statement and that has the OpenMP parallel for AST added to it. Anyway, I'd love to hear more thoughts on how you want to tackle outlining.

> #. Implement support of ``-fopenmp`` and ``-fno-openmp`` compiler options.

We have the -cc1 -fopenmp now; the driver-level options can wait until the feature is complete.

> #. Develop AST representation for each OpenMP directive and clause representing 
>    OpenMP constructions as statements.

Okay. Let's take a sample one.

> #. Implement parsing and semantic analysis for each directive using standard 
>    pragma processing approach (implies implementing of single PragmaHandler for 
>    all directives, parsing procedures for directives, clauses and their 
>    arguments, and semantic checking of all OpenMP construct).

Sure, let's take this in stages: pick an OpenMP directive and write a parser for it w/ tests. Then add some semantic analysis, then ASTs, and we'll see how things shape up.

> #. Implement CodeGen stage (to be discussed later) for each OpenMP construct.

Some of this will tie into the runtime. I'm most interested in your approach to handling outlining, because that's going to affect the ASTs.

> Some of OpenMP directives still could be represented as attributes, for
> example ``omp threadprivate`` directive. This directive specifies that variables 
> from a list following the directive are "replicated, with each thread having its
> own copy". This is a declarative directive, so it would be better to represent
> it as an attribute of a varible, not a statement.

That seems reasonable.

I think this is a good start. Looking forward to more patches!

	- Doug


> Best regards,
> Alexey Bataev
> =============
> Software Engineer
> Intel Compiler Team
> Intel Corp.
> 
>  
>> ----- Original Message -----
>> From: Chandler Carruth
>> Sent: 12/27/12 07:48 AM
>> To: Alexey Bataev
>> Subject: Re: [cfe-dev] [RFC] OpenMP Support in Clang
>> 
>> On Wed, Dec 26, 2012 at 8:28 AM, Alexey Bataev <a.bataev at gmx.com> wrote:
>> Hi All,
>> 
>> We'd like to make a proposal for OpenMP support in Clang as discussed later.
>> Included document contains some general design description and a proposal on
>> OpenMP constructs representation in AST.
>> We seek feedback on the proposed design and ways to improve it.
>> Main authors of the proposal are Alexey Bataev and Andrey Bokhanko.
>> The document in rst format is attached to the message.
>> OpenMP_design.rst
>> <http://clang-developers.42468.n3.nabble.com/file/n4029194/OpenMP_design.rst>
>>  
>> This link doesn't work for me -- at least it doesn't work the right way. It's not laid out as plain text but instead as raw html.
>>  
>> Maybe actually attach it via email rather than nabble's link-embedding approach? Dunno.
>>  
>> 
>> Yours,
>> Alexey Bataev
>> Andrey Bokhanko
>> =============
>> Software Engineers
>> Intel Compiler Team
>> Intel Corp.
>> 
>> 
>> 
>> --
>> View this message in context: http://clang-developers.42468.n3.nabble.com/RFC-OpenMP-Support-in-Clang-tp4029194.html
>> Sent from the Clang Developers mailing list archive at Nabble.com.
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>  
> 
> <OpenMP_design.rst>_______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130114/55355961/attachment.html>