On Wed, 2013-08-28 at 13:06 +0200, Jakub Jelinek wrote: > On Wed, Aug 28, 2013 at 12:39:00PM +0200, Richard Biener wrote: > > >From the accelerator BOF video I gather we agreed on using the GOMP > > representation as unified middle-end. What I didn't get is whether we > > agreed on libgomp being the unified single runtime (that eventually > > dispatches to accelerator specific runtimes, opened via dlopen)? > > I guess that is up to discussions.
Yes. We didn't have time to discuss this; also, my impression was that we (meaning people in the room) weren't ready to discuss this yet because there were too many open questions, including how the particular platforms/archs that we would be targeting would actually look like (e.g., on the Linux userspace side). > In the Intel MIC case (the only thing I've looked briefly at for how the > offloading works - the COI library) you can load binaries and shared > libraries either from files or from host memory image, so e.g. you can > embed the libgomp library, some kind of libm and some kind of libc > (would that be glibc, newlib, something else?) compiled for the target > into some data section inside of the plugin or something > (or load it from files of course). That's another interesting question: how do we deploy. The "static linking" into the plugin might be worthwhile if the number of "target libraries" is small. But if there are several, and/or if we want the libraries to be decoupled from each other (eg, to make updates easier), then we'd need a mechanism to load them. > No idea how you do this in the > HSAIL case, or PTX. Yes, this is something we should discuss at some point, for each platform that we want accelerators to be supported on. I'm not sure whether GCC is the optimal place for this conversation (GCC would rather be a user of whatever is built), but maybe it is in absence of alternatives :-) Looking at the Linux side of this is something that I'm interested in. Torvald
