AMDGPU: Support target triple OS component cuda

[yaxunl]

Summary

This patch allows AMDGPU backend consumes IR generated by clang for CUDA.

Patch by Greg Rodgers.

[arsenm]

You're using this just as an alias for AMDHSAOS. We shouldn't add something that behaves exactly the same

lib/Target/AMDGPU/SIISelLowering.cpp

5797

Dead code

[b-sumner]

In D42711#992503, @arsenm wrote:

You're using this just as an alias for AMDHSAOS. We shouldn't add something that behaves exactly the same

I agree. The IR should just get the right OS to start with.

[yaxunl]

I think the purpose of this patch is to get a similar usage of clang as nvptx when compiling CUDA, i.e., using cuda as OS instead of using amdhsa as OS and amdgiz as environment. This is more convenient for CUDA application developers since they just need to swap nvptx with amdgcn.

[b-sumner]

As I understand it, the option users pass to clang++ is --cuda-gpu-arch=<Arch>. Can't we arrange to generate the right triple if they use gfx900 or some other AMD target name for <Arch>?

[arsenm]

In D42711#992517, @yaxunl wrote:

I think the purpose of this patch is to get a similar usage of clang as nvptx when compiling CUDA, i.e., using cuda as OS instead of using amdhsa as OS and amdgiz as environment. This is more convenient for CUDA application developers since they just need to swap nvptx with amdgcn.

This is a frontend driver question at most. The backend shouldn't need to be aware of this

[yaxunl]

In D42711#992555, @arsenm wrote:

In D42711#992517, @yaxunl wrote:

I think the purpose of this patch is to get a similar usage of clang as nvptx when compiling CUDA, i.e., using cuda as OS instead of using amdhsa as OS and amdgiz as environment. This is more convenient for CUDA application developers since they just need to swap nvptx with amdgcn.

This is a frontend driver question at most. The backend shouldn't need to be aware of this

There are various places in clang where selection is done based on OS==CUDA. If we don't use that OS, we need more complex logic in clang for such choices. I can try making changes to clang to make it work, but I suspect there may be places using OS==CUDA is necessary since it may be needed before parsing the language options.

[b-sumner]

In D42711#993438, @yaxunl wrote:

In D42711#992555, @arsenm wrote:

In D42711#992517, @yaxunl wrote:

I think the purpose of this patch is to get a similar usage of clang as nvptx when compiling CUDA, i.e., using cuda as OS instead of using amdhsa as OS and amdgiz as environment. This is more convenient for CUDA application developers since they just need to swap nvptx with amdgcn.

This is a frontend driver question at most. The backend shouldn't need to be aware of this

There are various places in clang where selection is done based on OS==CUDA. If we don't use that OS, we need more complex logic in clang for such choices. I can try making changes to clang to make it work, but I suspect there may be places using OS==CUDA is necessary since it may be needed before parsing the language options.

Changing those selections make sense to me since was are adding support for a completely new and different target.

[jlebar]

In D42711#993457, @b-sumner wrote:

Changing those selections make sense to me since was are adding support for a completely new and different target.

As one of the CUDA maintainers, this also makes sense to me, although we're going to need tests and (to the extent possible) wrapper functions so that it doesn't break.

[yaxunl]

In D42711#993470, @jlebar wrote:

In D42711#993457, @b-sumner wrote:

Changing those selections make sense to me since was are adding support for a completely new and different target.

As one of the CUDA maintainers, this also makes sense to me, although we're going to need tests and (to the extent possible) wrapper functions so that it doesn't break.

There is another concern. If we need to identify IR originated from CUDA in AMDHSA OS, what should we do? Introduce CUDA again as an environment component?

[arsenm]

In D42711#993511, @yaxunl wrote:

In D42711#993470, @jlebar wrote:

In D42711#993457, @b-sumner wrote:

Changing those selections make sense to me since was are adding support for a completely new and different target.

As one of the CUDA maintainers, this also makes sense to me, although we're going to need tests and (to the extent possible) wrapper functions so that it doesn't break.

There is another concern. If we need to identify IR originated from CUDA in AMDHSA OS, what should we do? Introduce CUDA again as an environment component?

There shouldn't be any reason to do this. The IR shouldn't really care what the source was.

[yaxunl]

In D42711#993524, @arsenm wrote:

In D42711#993511, @yaxunl wrote:

In D42711#993470, @jlebar wrote:

In D42711#993457, @b-sumner wrote:

Changing those selections make sense to me since was are adding support for a completely new and different target.

As one of the CUDA maintainers, this also makes sense to me, although we're going to need tests and (to the extent possible) wrapper functions so that it doesn't break.

There is another concern. If we need to identify IR originated from CUDA in AMDHSA OS, what should we do? Introduce CUDA again as an environment component?

There shouldn't be any reason to do this. The IR shouldn't really care what the source was.

Then why do we need opencl environment component in the triple?

[arsenm]

In D42711#993538, @yaxunl wrote:

In D42711#993524, @arsenm wrote:

In D42711#993511, @yaxunl wrote:

In D42711#993470, @jlebar wrote:

In D42711#993457, @b-sumner wrote:

Changing those selections make sense to me since was are adding support for a completely new and different target.

As one of the CUDA maintainers, this also makes sense to me, although we're going to need tests and (to the extent possible) wrapper functions so that it doesn't break.

There is another concern. If we need to identify IR originated from CUDA in AMDHSA OS, what should we do? Introduce CUDA again as an environment component?

There shouldn't be any reason to do this. The IR shouldn't really care what the source was.

Then why do we need opencl environment component in the triple?

This specifies the ABI change for the entry point

[yaxunl]

no longer needed