[RFC] Introduce HIP language mode

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] Introduce HIP language mode

Manuel Klimek via cfe-dev
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

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

winmail.dat (22K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Introduce HIP language mode

Manuel Klimek via cfe-dev
On Mar 28, 2018, at 3:29 PM, Liu, Yaxun (Sam) via cfe-dev <[hidden email]> 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:

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.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Introduce HIP language mode

Manuel Klimek via cfe-dev

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

 

Yaxun (Sam) Liu

AMD

 

From: [hidden email] [mailto:[hidden email]]
Sent: Wednesday, March 28, 2018 4:47 PM
To: Liu, Yaxun (Sam) <[hidden email]>
Cc: cfe-dev ([hidden email]) <[hidden email]>; Tye, Tony <[hidden email]>; Sumner, Brian <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Introduce HIP language mode

 

On Mar 28, 2018, at 3:29 PM, Liu, Yaxun (Sam) via cfe-dev <[hidden email]> 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:

 

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.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Introduce HIP language mode

Manuel Klimek via cfe-dev
> On Apr 2, 2018, at 11:26 AM, Liu, Yaxun (Sam) <[hidden email]> wrote:
>
> 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.

John.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Introduce HIP language mode

Manuel Klimek via cfe-dev
On Mon, 2 Apr 2018, 09:01 John McCall via cfe-dev, <[hidden email]> wrote:
> On Apr 2, 2018, at 11:26 AM, Liu, Yaxun (Sam) <[hidden email]> wrote:
>
> 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.

John.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Introduce HIP language mode

Manuel Klimek via cfe-dev
In reply to this post by Manuel Klimek via cfe-dev
On 03/28/2018 12:29 PM, Liu, Yaxun (Sam) via cfe-dev 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 ).
>

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

> 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
>
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Introduce HIP language mode

Manuel Klimek via cfe-dev
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

-----Original Message-----
From: Tom Stellard [mailto:[hidden email]]
Sent: Monday, April 02, 2018 12:26 PM
To: Liu, Yaxun (Sam) <[hidden email]>; cfe-dev ([hidden email]) <[hidden email]>
Cc: Tye, Tony <[hidden email]>; Sumner, Brian <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Introduce HIP language mode

On 03/28/2018 12:29 PM, Liu, Yaxun (Sam) via cfe-dev 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 ).
>

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

> 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
>
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev