AMD GCN port

[Andrew Stubbs]

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.