This patch allows AMDGPU backend consumes IR generated by clang for CUDA.
Patch by Greg Rodgers.
Differential D42711
AMDGPU: Support target triple OS component cuda yaxunl on Jan 30 2018, 2:48 PM. Authored by
Details
This patch allows AMDGPU backend consumes IR generated by clang for CUDA. Patch by Greg Rodgers.
Diff Detail Event TimelineComment Actions You're using this just as an alias for AMDHSAOS. We shouldn't add something that behaves exactly the same
Comment Actions 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. Comment Actions 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>? Comment Actions This is a frontend driver question at most. The backend shouldn't need to be aware of this Comment Actions 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. Comment Actions Changing those selections make sense to me since was are adding support for a completely new and different target. Comment Actions 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. Comment Actions 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? Comment Actions There shouldn't be any reason to do this. The IR shouldn't really care what the source was. |