[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
example:
- 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.
Joel
> 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.html>
More information about the cfe-dev
mailing list