On Wed, May 9, 2018 at 6:35 PM, Andrew Stubbs <a...@codesourcery.com> wrote: > 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?
Sounds good but I'd not do 1. given the github repo can serve as archiving point, too. Having 2. doesn't sound too useful over 3. so in the end I'd do only 3. and 4. Of course 1 and 2 might help you in doing 3 and 4. Richard. > -- > Andrew Stubbs > Mentor Graphics / CodeSourcery.
