This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

AMD GCN port


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]