This patch allows AMDGPU backend consumes IR generated by clang for CUDA.
Patch by Greg Rodgers.
Paths
| Differential D42711
AMDGPU: Support target triple OS component cuda AbandonedPublic Authored by yaxunl on Jan 30 2018, 2:48 PM.
Details
Summary This patch allows AMDGPU backend consumes IR generated by clang for CUDA. Patch by Greg Rodgers.
Diff Detail Event TimelineHerald added subscribers: t-tye, tpr, dstuttard and 3 others. · View Herald TranscriptJan 30 2018, 2:48 PM Comment Actions You're using this just as an alias for AMDHSAOS. We shouldn't add something that behaves exactly the same
This revision now requires changes to proceed.Jan 30 2018, 2:55 PM Comment Actions
I agree. The IR should just get the right OS to start with. 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. Comment Actions
Then why do we need opencl environment component in the triple? Comment Actions
This specifies the ABI change for the entry point
Revision Contents
Diff 132057 lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp
lib/Target/AMDGPU/AMDGPUPromoteAlloca.cpp
lib/Target/AMDGPU/AMDGPUSubtarget.h
lib/Target/AMDGPU/AMDGPUTargetMachine.cpp
lib/Target/AMDGPU/AsmParser/AMDGPUAsmParser.cpp
lib/Target/AMDGPU/MCTargetDesc/AMDGPUAsmBackend.cpp
lib/Target/AMDGPU/SIISelLowering.cpp
lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp
|
Dead code