On 09/13/13 10:34, Michael Zolotukhin wrote:
Hi Jakub et al.,
We prepared a draft for design document for offloading support in GCC - could
you please take a look? It is intended to give a common comprehension of what
is going on in this part.
This is an interesting design. It appears similar to how we'd envisioned
implementing openacc support -- namely leverage the LTO machinery to communicate
from the host compiler to the device compiler. Your design looks more detailed,
which is good.
Are you envisioning the device compilers to be stand alone compilers, built
separately. Or are you envisioning extending the configuration machinery by
adding something like --enable-acclerator=<list> so that:
.../configure --target=x86_64-linux --enable-accelerator=foo,baz
causes
* a build of an x86_64 compiler aware of the foo and baz accelerators
* build of an appropriate runtime support library
* a build of a foo lto accelerator backend, assembler (and linker?)
* (if needed) build of a foo support library
* a build of a baz lto accelerator backend
* (if needed) build of a baz support library, assembler (and linker?)
or are you expecting something more like 3 separate configures & build?
.../configure --target=x86_64-linux --enable-accelerator=foo,baz
.../configure --target=foo --enable-languages=lto-accelerator
.../configure --target=baz --enable-languages=lto-accelerator
I'd been imagining the former scheme, as it provides for a more integrated
build, fwiw.
nathan
