Honza, Martin,
Further to our conversation on IRC ...
We have just completed work on a GCN3 & GCN5 port intended for running
OpenMP and OpenACC offload kernels on AMD Fiji and Vega discrete GPUs.
Unfortunately Carrizo is probably broken because we don't have one to
test, and the APUs use shared memory and XNACK, which we've not paid any
attention to.
There will be a binary release available soon(ish).
Apologies the development schedule has made it hard to push the work
upstream, but now it is time.
I've posted the code to Github for reference:
https://github.com/ams-cs/gcc
https://github.com/ams-cs/newlib
We're using LLVM 6 for the assembler and linker; there's no binutils port.
It should be possible to build a "standalone" amdgcn-none-amdhsa
compiler that can run code via the included "gcn-run" loader tool (and
the HSA runtime). This can be used to run the testsuite, with a little
dejagnu config trickery.
It should also be possible to build an x86_64-linux-gnu compiler with
--enable-offload-target=gcn, and a matching amdgcn-none-amdhsa compiler
with --enable-as-accelerator-for=x86_64-linux-gnu, and have them run
code offloaded with OpenMP or OpenACC directives.
The code is based on Honza's original port, rebased to GCC 7.3.
I'd like to agree an upstreaming strategy that
a) gets basic GCN support into trunk soonish. We'll need to get a few
middle/front end patches approved, and probably update a few back-end
hooks, but this ought to be easy enough.
b) gets trunk OpenMP/OpenACC to work for GCN, eventually. I'm expecting
some pain in libgomp here.
c) gives me a stable base from which to make binary releases (i.e. not
trunk).
d) allows me to use openacc-gcc-8-branch without too much duplication of
effort.
How about the following strategy?
1. Create "gcn-gcc-7-branch" to archive the current work. This would be
a source for merges (or cherry-picking), but I'd not expect much future
development. Initially it would have the same content as the Github
repository above.
2. Create "gcn-gcc-8-branch" with a merger of "gcc-8-branch" and
"gcn-gcc-7-branch". This would be broken w.r.t. libgomp, initially, but
get fixed up in time. It would receive occasional merges from the
release branch. I expect to do GCN back-end development work here.
3. Create "gcn-openacc-gcc-8-branch" from the new "gcn-gcc-8-branch",
and merge in "openacc-gcc-8-branch". This will hold offloading patches
not compatible with trunk, and receive updated GCN changes via merge. I
intend to deliver my next binary release from this branch.
4. Replace/update the existing "gcn" branch with a merger of "trunk" and
"gcn-gcc-8-branch" (not the OpenACC branch). This would be merged to
trunk, and possibly retired, as soon as possible. I imagine bits will
have to be submitted as patches, and then the back-end merged as a whole.
trunk
|\
| gcc-7-branch
| |\
| : gcn-gcc-7-branch
| \
|\ '--------.
| gcc-8-branch |
| | \ '------------. |
| : openacc-gcc-8-branch gcn-gcc-8-branch
| \ / |
| gcn-openacc-8-branch |
|\ ,---------------------------------'
| gcn
|/
gcc-9
It's slightly complex to describe, but hopefully logical and workable.
Comments? Better suggestions?
--
Andrew Stubbs
Mentor Graphics / CodeSourcery.
