[cfe-dev] [RFC] Introduce HIP language mode

[John McCall via cfe-dev]

> On Mar 28, 2018, at 3:29 PM, Liu, Yaxun (Sam) via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> HIP is a language similar to CUDA (https://github.com/ROCm-Developer-Tools/HIP/blob/master/docs/markdown/hip_kernel_language.md  ).
> The language syntax is very similar, which allows a hip program to be compiled as a CUDA program by Clang. The main difference
> is the host API. HIP has a set of vendor neutral host API which can be implemented on different platforms. Currently there is open source
> implementation of HIP runtime on amdgpu target (https://github.com/ROCm-Developer-Tools/HIP ).
> 
> We have a working implementation of HIP compiler based on clang thanks to Greg Rodgers' work and we would like to upstream it. As an initial step, we created a Phabricator
> Review https://reviews.llvm.org/D44984 for adding support of file type hip and language option HIP.
> 
> When hip file is compiled, both LangOpts.CUDA and LangOpts.HIP is turned on. This allows compilation of hip program as CUDA
> in most cases and only special handling of hip program is needed LangOpts.HIP is checked.
> 
> This patch also adds support of kernel launching of HIP program using HIP host API.
> 
> The next patch will be the toolchain changes to support HIP. Basically HIP has its own open source header files and device libraries which may be ported to different targets/platforms.
> 
> We plan to continue upstreaming our support of HIP until it becomes mature enough to support major machine learning applications ported to HIP, e.g. TensorFlow https://github.com/ROCmSoftwarePlatform/tensorflow .

Clang has a written policy about contributing new extensions, which you can find here:
  https://clang.llvm.org/get_involved.html <https://clang.llvm.org/get_involved.html>

It seems to me that that's the bar that HIP needs to meet in order to be accepted into Clang.  Would you mind running through the seven criteria listed on that page?  To make this easier, I'll go ahead and quote them:

Clang has always been designed as a platform for experimentation, allowing programmers to easily extend the compiler to support great new language features and tools. At some point, the authors of these extensions may propose that the extensions become a part of Clang itself, to benefit the whole Clang community. But not every idea--not even every great idea--should become part of Clang. Extensions (particularly language extensions) pose a long-term maintenance burden on Clang, and therefore the benefits of the extension must outweight those costs. Hence, these are the seven criteria used to evaluate the merits of a proposed extension:

	• Evidence of a significant user community: This is based on a number of factors, including an actual, existing user community, the perceived likelihood that users would adopt such a feature if it were available, and any "trickle-down" effects that come from, e.g., a library adopting the feature and providing benefits to its users.

	• A specific need to reside within the Clang tree: There are some extensions that would be better expressed as a separate tool, and should remain as separate tools even if they end up being hosted as part of the LLVM umbrella project.

	• A complete specification: The specification must be sufficient to understand the design of the feature as well as interpret the meaning of specific examples. The specification should be detailed enough that another compiler vendor could conceivably implement the feature.

	• Representation within the appropriate governing organization: For extensions to a language governed by a standards committee (C, C++, OpenCL), the extension itself must have an active proposal and proponent within that committee and have a reasonable chance of acceptance. Clang should drive the standard, not diverge from it. This criterion does not apply to all extensions, since some extensions fall outside of the realm of the standards bodies.

	• A long-term support plan: Contributing a non-trivial extension to Clang implies a commitment to supporting that extension, improving the implementation and specification as Clang evolves. The capacity of the contributor to make that commitment is as important as the commitment itself.

	• A high-quality implementation: The implementation must fit well into Clang's architecture, follow LLVM's coding conventions, and meet Clang's quality standards, including high-quality diagnostics and rich AST representations. This is particularly important for language extensions, because users will learn how those extensions work through the behavior of the compiler.

	• A proper test suite: Extensive testing is crucial to ensure that the language extension is not broken by ongoing maintenance in Clang. The test suite should be complete enough that another compiler vendor could conceivably validate their implementation of the feature against it.

To get you started, I'm willing to stipulate that HIP meets a few of these criteria (although other people may disagree):

- It has a clear need to reside within the Clang tree because it's a variant language mode with slightly different Sema and IRGen rules.  That would be very hard to maintain as a separate project.

- Assuming that you are willing to gradually upstream the work instead of dumping it all in as a few massive patches, I will accept that it has a high-quality implementation that meeds our architectural and quality requirements.

Please address the other five points, though.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180328/98ebe55f/attachment.html>