This patch adds AMDGPUOpenMPToolChain for supporting OpenMP
offloading to AMD GPU's.
Originally authored by Greg Rodgers
Differential D94961
[OpenMP] Add OpenMP offloading toolchain for AMDGPU pdhaliwal on Jan 19 2021, 3:45 AM. Authored by
Details This patch adds AMDGPUOpenMPToolChain for supporting OpenMP Originally authored by Greg Rodgers
Diff Detail
Event TimelineComment Actions This patch was written, roughly, by:
The idea is to move language-independent but amdgcn-specific code into ROCMToolChain. Some has already gone in, others (like computeMSVCVersion) will likely move too. Regarding the rest of the end to end stack:
Regarding tests (which need the unimplemented bit filled in with the next patch):
Comment Actions Won't this just prevent us from building clang due to the missing cmake changes? We need somewhat testable chunks. Comment Actions Could you add the tests for the tools invocation to check that the newly added classes/functions correctly translate options/flags? Comment Actions
It compiles and builds fine, however, I wasn't actually aware such sanity checking being present. It turns out The idea for this patch was basically to introduce AMDGPUToolChain classes without much of the functionality in order I have updated this patch to now include somewhat functional driver along with tests. Comment Actions
Comment Actions The deviceRTL is changing from cuda/hip to openmp at present. It would be good to be able to compile that as openmp for amdgpu, which needs a patch roughly like this and probably some follow up. It's plausible that the contents of this file are only really of interest to AMD people, in which case we should probably land it in order to iterate in tree instead of downstream. It now has the cmake hook and a proof of concept test case. @ABataev @grokos @jdoerfert your guidance would be very welcome, but equally if you'd prefer leave us to sink or swim that's completely reasonable too. Thanks! Comment Actions Overall, looks reasonable. I'm not a fan of the way things are hooked up but that is also true for the NVPTX toolchain and for now unavoidable I guess. Some nits below.
Comment Actions This is loosely based on the nvptx and hip toolchain files, but looking at others in clang the style seems similar.
Comment Actions I believe this is 'safe', in the sense that it can't break anything other than AMDGPU's openmp implementation, which doesn't work yet anyway. The change to non-amd code is to OpenMPActionBuilder, and while parsing -march=gfx isn't pretty, it won't fire on nvptx. I'm not particularly confident it is correct, but it's hard to do comprehensive testing before there's an end to end spike. I'd like to iterate in tree, with an expectation that parts of this will need to change - @jdoerfert does the OpenMP patch look adequate for now?
Comment Actions Generally OK, the more I look at it the more things pop up. Other than my comments, I'm fine with this going in.
Comment Actions Addressed review comments.
Comment Actions After addressing the review comments, I have internally verified changes on few simple test programs. They seem to be working fine.
Comment Actions Looks much simpler, thanks!
Comment Actions
|
This follows the same logic as nvptx so is likely to be correct