[cfe-dev] RFC: clacc: translating OpenACC to OpenMP in clang

Joel E. Denny via cfe-dev cfe-dev at lists.llvm.org
Fri Dec 8 07:51:52 PST 2017

Hi Jeff, Hal,

Thanks for your feedback.  My comments are inline below.

On Tue, Dec 5, 2017 at 6:43 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> On 12/05/2017 05:11 PM, Jeff Hammond via cfe-dev wrote:
> All of the usage of OpenACC outside of benchmarks/research that I know
> about is done in Fortran.
I agree that it's easier to find real apps that use OpenACC in Fortran than
those that use OpenACC in C/C++.  However, the latter certainly exist.  For

   - http://mrfil.github.io/PowerGrid/
   - https://nek5000.mcs.anl.gov/ (look at the openacc branch in github)
   - https://nekcem.mcs.anl.gov/

  Can you provide a list of C/C++ applications using OpenACC today and
> estimate the number of users that will benefit from this feature?
> Such lists exist, although I don't know what can be shared (and Oak Ridge
> likely has better lists in this regard than I do).

I'll look for a better list that I can share.

> I can tell you, from my own experience, that we're seeing an increase in
> development using OpenACC, in both C/C++ and Fortran, over the last couple
> of years (essentially because the compiler technology has improved to the
> point where that is now a potentially-productive choice).

Providing support in a production-quality, open-source compiler tool chain
like LLVM will hopefully accelerate this trend.


> Also, we have a strong desire to enable tooling over code bases using
> OpenACC. Among many other things, at some point we'll likely want the
> option to automatically migrate much of this code to using OpenMP. Having
> an OpenACC-enabled Clang, with an implementation that maps to OpenMP, is an
> important step in that process.
>  -Hal
> Thanks,
> Jeff
> On Tue, Dec 5, 2017 at 11:06 AM, Joel E. Denny via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>> Hi,
>> We are working on a new project, clacc, that extends clang with OpenACC
>> support.  Clacc's approach is to translate OpenACC (a descriptive language)
>> to OpenMP (a prescriptive language) and thus to build on clang's existing
>> OpenMP support.  While we plan to develop clacc to support our own
>> research, an important goal is to contribute clacc as a production-quality
>> component of upstream clang.
>> We have begun implementing an early prototype of clacc.  Before we get
>> too far into the implementation, we would like to get feedback from the
>> LLVM community to help ensure our design would ultimately be acceptable for
>> contribution.  For that purpose, below is an analysis of several high-level
>> design alternatives we have considered and their various features.  We
>> welcome any feedback.
>> Thanks.
>> Joel E. Denny
>> Future Technologies Group
>> Oak Ridge National Laboratory
>> Design Alternatives
>> -------------------
>> We have considered three design alternatives for the clacc compiler:
>> 1. acc src  --parser-->                     omp AST  --codegen-->  LLVM
>> IR + omp rt calls
>> 2. acc src  --parser-->  acc AST                     --codegen-->  LLVM
>> IR + omp rt calls
>> 3. acc src  --parser-->  acc AST  --ttx-->  omp AST  --codegen-->  LLVM
>> IR + omp rt calls
>> In the above diagram:
>> * acc src = C source code containing acc constructs.
>> * acc AST = a clang AST in which acc constructs are represented by
>>   nodes with acc node types.  Of course, such node types do not
>>   already exist in clang's implementation.
>> * omp AST = a clang AST in which acc constructs have been lowered
>>   to omp constructs represented by nodes with omp node types.  Of
>>   course, such node types do already exist in clang's
>>   implementation.
>> * parser = the existing clang parser and semantic analyzer,
>>   extended to handle acc constructs.
>> * codegen = the existing clang backend that translates a clang AST
>>   to LLVM IR, extended if necessary (depending on which design is
>>   chosen) to perform codegen from acc nodes.
>> * ttx (tree transformer) = a new clang component that transforms
>>   acc to omp in clang ASTs.
>> Design Features
>> ---------------
>> There are several features to consider when choosing among the designs
>> in the previous section:
>> 1. acc AST as an artifact -- Because they create acc AST nodes,
>>    designs 2 and 3 best facilitate the creation of additional acc
>>    source-level tools (such as pretty printers, analyzers, lint-like
>>    tools, and editor extensions).  Some of these tools, such as pretty
>>    printing, would be available immediately or as minor extensions of
>>    tools that already exist in clang's ecosystem.
>> 2. omp AST/source as an artifact -- Because they create omp AST
>>    nodes, designs 1 and 3 best facilitate the use of source-level
>>    tools to help an application developer discover how clacc has
>>    mapped his acc to omp, possibly in order to debug a mapping
>>    specification he has supplied.  With design 2 instead, an
>>    application developer has to examine low-level LLVM IR + omp rt
>>    calls.  Moreover, with designs 1 and 3, permanently migrating an
>>    application's acc source to omp source can be automated.
>> 3. omp AST for mapping implementation -- Designs 1 and 3 might
>>    also make it easier for the compiler developer to reason about and
>>    implement mappings from acc to omp.  That is, because acc and omp
>>    syntax is so similar, implementing the translation at the level of
>>    a syntactic representation is probably easier than translating to
>>    LLVM IR.
>> 4. omp AST for codegen -- Designs 1 and 3 simplify the
>>    compiler implementation by enabling reuse of clang's existing omp
>>    support for codegen.  In contrast, design 2 requires at least some
>>    extensions to clang codegen to support acc nodes.
>> 5. Full acc AST for mapping -- Designs 2 and 3 potentially
>>    enable the compiler to analyze the entire source (as opposed to
>>    just the acc construct currently being parsed) while choosing the
>>    mapping to omp.  It is not clear if this feature will prove useful,
>>    but it might enable more optimizations and compiler research
>>    opportunities.
>> 6. No acc node classes -- Design 1 simplifies the compiler
>>    implementation by eliminating the need to implement many acc node
>>    classes.  While we have so far found that implementing these
>>    classes is mostly mechanical, it does take a non-trivial amount of
>>    time.
>> 7. No omp mapping -- Design 2 does not require acc to be mapped to
>>    omp.  That is, it is conceivable that, for some acc constructs,
>>    there will prove to be no omp syntax to capture the semantics we
>>    wish to implement.  It is also conceivable that we might one day
>>    want to represent some acc constructs directly as extensions to
>>    LLVM IR, where some acc analyses or optimizations might be more
>>    feasible to implement.  This possibility dovetails with recent
>>    discussions in the LLVM community about developing LLVM IR
>>    extensions for various parallel programming models.
>> Because of features 4 and 6, design 1 is likely the fastest design to
>> implement, at least at first while we focus on simple acc features and
>> simple mappings to omp.  However, we have so far found no advantage
>> that design 1 has but that design 3 does not have except for feature
>> 6, which we see as the least important of the above features in the
>> long term.
>> The only advantage we have found that design 2 has but that design 3
>> does not have is feature 7.  It should be possible to choose design 3
>> as the default but, for certain acc constructs or scenarios where
>> feature 7 proves important (if any), incorporate design 2.  In other
>> words, if we decide not to map a particular acc construct to any omp
>> construct, ttx would leave it alone, and we would extend codegen to
>> handle it directly.
>> Conclusions
>> -----------
>> For the above reasons, and because design 3 offers the cleanest
>> separation of concerns, we have chosen design 3 with the possibility
>> of incorporating design 2 where it proves useful.
>> Because of the immutability of clang's AST, the design of our proposed
>> ttx component requires careful consideration.  To shorten this initial
>> email, we have omitted those details for now, but we will be happy to
>> include them as the discussion progresses.
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> --
> Jeff Hammond
> jeff.science at gmail.com
> http://jeffhammond.github.io/
> _______________________________________________
> cfe-dev mailing listcfe-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171208/fa9cc0b8/attachment-0001.html>

More information about the cfe-dev mailing list