[RFC] Introduce HIP language mode

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 .
Any comments are welcome.

Thanks.

Yaxun (Sam) Liu

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.

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

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

Yaxun (Sam) Liu

AMD

Thanks. I feel this is a strong enough case for accepting HIP as a new language mode.
We should give other people an opportunity to weigh in before we start landing any
patches, but in the meantime, I'll go ahead and start reviewing.

John.

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

Thanks. I feel this is a strong enough case for accepting HIP as a new language mode.
We should give other people an opportunity to weigh in before we start landing any
patches, but in the meantime, I’ll go ahead and start reviewing.

I’m satisfied by those answers too.

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

What's the relationship between the HIP language mode and hcc? Is the
HIP language mode intended to replace the current hip + hcc stack?

-Tom

Hi Tom,

HIP on HCC is an existing open-source out-of-tee implementation of HIP. HIP on clang is a new implementation which is independent of HCC. Since HIP is very similar to CUDA, implementing it directly in clang trunk make it easier to upstream therefore result in higher quality.

After HIP is fully supported in clang trunk, we may consider removing HCC specific implementation details from HIP runtime. Of course HCC as an independent language has its own advantages and will still continue to exist.

Sam

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 .
Any comments are welcome.

Is there a public git repo with the patches you are pushing upstream?

-Tom

Yes. http://github.com/radeonopencompute/clang amd-hip-rebase branch.

Sam

Yes. http://github.com/radeonopencompute/clang amd-hip-rebase branch.

Thanks and can I use HIP from ROCm 1.8 with this branch or do I need
to use a different build of HIP?

-Tom

Since it is still under development, you need to build HIP by yourself with https://github.com/ROCm-Developer-Tools/HIP hip-clang branch and also you need to build amdgcn device library by yourself with GitHub - RadeonOpenCompute/ROCm-Device-Libs: ROCm Device Libraries amd-hip branch.

They work with ROCm master branch for me. I think they should also work with ROCm 1.8.

Sam