<div dir="ltr"><div>Hi Jeff, Hal,<br><br></div>Thanks for your feedback. My comments are inline below.<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 5, 2017 at 6:43 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="gmail-">
<div class="gmail-m_-8119247946472987079moz-cite-prefix">On 12/05/2017 05:11 PM, Jeff Hammond
via cfe-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">All of the usage of OpenACC outside of
benchmarks/research that I know about is done in Fortran.</div></blockquote></span></div></blockquote><div><div><br></div><div>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:<br></div><ul><li><font size="2"><a href="http://mrfil.github.io/PowerGrid/" target="_blank">http://mrfil.github.io/PowerGr<wbr>id/</a></font></li><li><font size="2"><a href="https://nek5000.mcs.anl.gov/" target="_blank">https://nek5000.mcs.anl.gov/</a> (look at the openacc branch in github)<span class="gmail-m_1245474332041707114gmail-m_-24628511979068677gmail-formula-content"><span dir="auto" class="gmail-m_1245474332041707114gmail-m_-24628511979068677gmail-string"></span></span></font></li><li><font size="2"><a href="https://nekcem.mcs.anl.gov/" target="_blank"><span class="gmail-m_1245474332041707114gmail-m_-24628511979068677gmail-formula-content"><span dir="auto" class="gmail-m_1245474332041707114gmail-m_-24628511979068677gmail-string">https://nekcem.mcs.anl.gov/</span></span></a></font></li></ul><p><br></p></div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-"><blockquote type="cite"><div dir="ltr"> Can
you provide a list of C/C++ applications using OpenACC today and
estimate the number of users that will benefit from this
feature?</div>
</blockquote>
<br></span>
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).</div></blockquote><div><br></div><div>I'll look for a better list that I can share.</div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"> 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).<br></div></blockquote><div><br></div><div>Providing support in a production-quality, open-source compiler tool
chain like LLVM will hopefully accelerate this trend.</div><div><br></div><div>Joel</div><div><br></div><div></div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
<br>
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.<br>
<br>
-Hal<div><div class="gmail-h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div><br>
</div>
<div>Thanks,<br>
<br>
Jeff</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Dec 5, 2017 at 11:06 AM, Joel
E. Denny via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div><span class="gmail-m_-8119247946472987079m_-2026156677408403204gmail-m_1339134059082687238gmail-m_-1727004882907755355gmail-gI"><span>Hi,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks.<br>
<br>
Joel E. Denny</span></span></div>
<div><span class="gmail-m_-8119247946472987079m_-2026156677408403204gmail-m_1339134059082687238gmail-m_-1727004882907755355gmail-gI"><span>Future
Technologies Group<br>
Oak Ridge National Laboratory</span></span></div>
<div><span class="gmail-m_-8119247946472987079m_-2026156677408403204gmail-m_1339134059082687238gmail-m_-1727004882907755355gmail-gI"><span><br>
</span></span></div>
<div><span class="gmail-m_-8119247946472987079m_-2026156677408403204gmail-m_1339134059082687238gmail-m_-1727004882907755355gmail-gI"><span><span style="font-family:monospace,monospace"><br>
</span></span></span></div>
<div><span class="gmail-m_-8119247946472987079m_-2026156677408403204gmail-m_1339134059082687238gmail-m_-1727004882907755355gmail-gI"><span><span style="font-family:monospace,monospace">Design
Alternatives<br>
-------------------<br>
<br>
We have considered three design alternatives for
the clacc compiler:<br>
<br>
1. acc src --parser--> <wbr>
omp AST --codegen--> LLVM IR + omp rt calls<br>
2. acc src --parser--> acc
AST --codegen--> LLVM IR +
omp rt calls<br>
3. acc src --parser--> acc AST --ttx-->
omp AST --codegen--> LLVM IR + omp rt calls<br>
<br>
In the above diagram:<br>
<br>
* acc src = C source code containing acc
constructs.<br>
* acc AST = a clang AST in which acc constructs
are represented by<br>
nodes with acc node types. Of course, such node
types do not<br>
already exist in clang's implementation.<br>
* omp AST = a clang AST in which acc constructs
have been lowered<br>
to omp constructs represented by nodes with omp
node types. Of<br>
course, such node types do already exist in
clang's<br>
implementation.<br>
* parser = the existing clang parser and semantic
analyzer,<br>
extended to handle acc constructs.<br>
* codegen = the existing clang backend that
translates a clang AST<br>
to LLVM IR, extended if necessary (depending on
which design is<br>
chosen) to perform codegen from acc nodes.<br>
* ttx (tree transformer) = a new clang component
that transforms<br>
acc to omp in clang ASTs.<br>
<br>
Design Features<br>
---------------<br>
<br>
There are several features to consider when
choosing among the designs<br>
in the previous section:<br>
<br>
1. acc AST as an artifact -- Because they create
acc AST nodes,<br>
designs 2 and 3 best facilitate the creation of
additional acc<br>
source-level tools (such as pretty printers,
analyzers, lint-like<br>
tools, and editor extensions). Some of these
tools, such as pretty<br>
printing, would be available immediately or as
minor extensions of<br>
tools that already exist in clang's ecosystem.<br>
<br>
2. omp AST/source as an artifact -- Because they
create omp AST<br>
nodes, designs 1 and 3 best facilitate the use
of source-level<br>
tools to help an application developer discover
how clacc has<br>
mapped his acc to omp, possibly in order to
debug a mapping<br>
specification he has supplied. With design 2
instead, an<br>
application developer has to examine low-level
LLVM IR + omp rt<br>
calls. Moreover, with designs 1 and 3,
permanently migrating an<br>
application's acc source to omp source can be
automated.<br>
<br>
3. omp AST for mapping implementation -- Designs 1
and 3 might<br>
also make it easier for the compiler developer
to reason about and<br>
implement mappings from acc to omp. That is,
because acc and omp<br>
syntax is so similar, implementing the
translation at the level of<br>
a syntactic representation is probably easier
than translating to<br>
LLVM IR.<br>
<br>
4. omp AST for codegen -- Designs 1 and 3 simplify
the<br>
compiler implementation by enabling reuse of
clang's existing omp<br>
support for codegen. In contrast, design 2
requires at least some<br>
extensions to clang codegen to support acc
nodes.<br>
<br>
5. Full acc AST for mapping -- Designs 2 and 3
potentially<br>
enable the compiler to analyze the entire
source (as opposed to<br>
just the acc construct currently being parsed)
while choosing the<br>
mapping to omp. It is not clear if this
feature will prove useful,<br>
but it might enable more optimizations and
compiler research<br>
opportunities.<br>
<br>
6. No acc node classes -- Design 1 simplifies the
compiler<br>
implementation by eliminating the need to
implement many acc node<br>
classes. While we have so far found that
implementing these<br>
classes is mostly mechanical, it does take a
non-trivial amount of<br>
time.<br>
</span></span></span></div>
<span style="font-family:monospace,monospace"><br>
7. No omp mapping -- Design 2 does not require acc to be
mapped to<br>
omp. That is, it is conceivable that, for some acc
constructs,<br>
there will prove to be no omp syntax to capture the
semantics we<br>
wish to implement. It is also conceivable that we
might one day<br>
want to represent some acc constructs directly as
extensions to<br>
LLVM IR, where some acc analyses or optimizations
might be more<br>
feasible to implement. This possibility dovetails
with recent<br>
discussions in the LLVM community about developing
LLVM IR<br>
extensions for various parallel programming models.</span><span style="font-family:monospace,monospace"><br>
<br>
<span class="gmail-m_-8119247946472987079m_-2026156677408403204gmail-m_1339134059082687238gmail-m_-1727004882907755355gmail-gI"><span></span></span></span>
<div>
<div><span class="gmail-m_-8119247946472987079m_-2026156677408403204gmail-m_1339134059082687238gmail-m_-1727004882907755355gmail-gI"><span><span style="font-family:monospace,monospace">Because
of features 4 and 6, design 1 is likely the
fastest design to<br>
implement, at least at first while we focus on
simple acc features and<br>
simple mappings to omp. However, we have so far
found no advantage<br>
that design 1 has but that design 3 does not
have except for feature<br>
6, which we see as the least important of the
above features in the<br>
long term.<br>
<br>
The only advantage we have found that design 2
has but that design 3<br>
does not have is feature 7. It should be
possible to choose design 3<br>
as the default but, for certain acc constructs
or scenarios where<br>
feature 7 proves important (if any), incorporate
design 2. In other<br>
words, if we decide not to map a particular acc
construct to any omp<br>
construct, ttx would leave it alone, and we
would extend codegen to<br>
handle it directly.<br>
<br>
Conclusions<br>
-----------<br>
<br>
For the above reasons, and because design 3
offers the cleanest<br>
separation of concerns, we have chosen design 3
with the possibility<br>
of incorporating design 2 where it proves
useful.<br>
<br>
Because of the immutability of clang's AST, the
design of our proposed<br>
ttx component requires careful consideration.
To shorten this initial<br>
email, we have omitted those details for now,
but we will be happy to<br>
include them as the discussion progresses.</span><br>
</span></span></div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail-m_-8119247946472987079gmail_signature">Jeff
Hammond<br>
<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br>
<a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>
</div>
<br>
<fieldset class="gmail-m_-8119247946472987079mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
cfe-dev mailing list
<a class="gmail-m_-8119247946472987079moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<a class="gmail-m_-8119247946472987079moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<br>
</div></div><span class="gmail-HOEnZb"><font color="#888888"><pre class="gmail-m_-8119247946472987079moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</font></span></div>
</blockquote></div><br></div></div>