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

Mon Apr 2 08:26:53 PDT 2018

Thanks John, my reply is below (with contribution from Tony Tye and Ben Sander) .

Yaxun (Sam) Liu
AMD

From: rjmccall at apple.com [mailto:rjmccall at apple.com]
Sent: Wednesday, March 28, 2018 4:47 PM
To: Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>
Cc: cfe-dev (cfe-dev at lists.llvm.org) <cfe-dev at lists.llvm.org>; Tye, Tony <Tony.Tye at amd.com>; Sumner, Brian <Brian.Sumner at amd.com>
Subject: Re: [cfe-dev] [RFC] Introduce HIP language mode

On Mar 28, 2018, at 3:29 PM, Liu, Yaxun (Sam) via cfe-dev <cfe-dev at lists.llvm.org<mailto: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

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.

HIP is a single-source C++ based GPGPU offloading language. It currently supports AMD and NVIDIA GPUs. It is available on github (https://github.com/ROCm-Developer-Tools/HIP) and currently has >1k star rating. It has been distributed as part of ROCm and includes an ever increasing number of ported applications and frameworks including TensorFlow, Caffe, MXNet, PyTorch, and BLAS.  (see https://github.com/ROCmSoftwarePlatform). The users of HIP cover Top 500 companies, university students and researchers. Given that HIP is an open source, vendor neutral GPGPU compute language that can be ported to any platform, it is expected that its adoption will continue.

   • 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.

John McCall: “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.”

As John has commented, HIP is better as part of clang instead of a separate 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.

The HIP kernel language  guide is essentially the language specification: https://github.com/ROCm-Developer-Tools/HIP/blob/master/docs/markdown/hip_kernel_language.md

The documentations about other aspects of HIP language are also available at: https://github.com/ROCm-Developer-Tools/HIP

   • 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.

HIP is developed and maintained by AMD as an open source project.

   • 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.

The AMD compiler team is committed to continued development, maintenance and testing of the HIP compiler.

   • 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.

John McCall: “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 meets our architectural and quality requirements.”

As John suggested, AMD is planning to upstream our implementation by small incremental patches instead of a single large patch, and so each patch will go through strict review process to guarantee code quality.

   • 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.

HIP has a comprehensive test suite available at: https://github.com/ROCm-Developer-Tools/HIP/tree/master/tests

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/20180402/f7ea4b75/attachment.html>