> > 1.2. Linking
> >
> > When all source files are compiled, a linker is invoked. The linker is
> > passed
> > a special option to invoke openmp-plugin. The plugin is responsible for
> > producing target-side executables - for each target it calls the
> > corresponding
> > target compiler and
> But I doubt dirent.h is portable to all targets we support, so I believe it
> needs another configure test, and perhaps we want to define some macro
> whether we actually support offloading at all (HAVE_DLFCN_H would be one
> precondition, HAVE_DIRENT_H (with opendir etc.) another one (for this t
Hi Jakub,
Here is the first patch for adding plugins support in libgomp - could you please
take a look at it?
I changed configure.ac to add dl-library, but I am not sure if I regenerated all
related to configure files properly. I'd appreciate your help here, if I did
it wrong.
Any feedback is we
Hi Nathan,
> 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.
Thanks, do you have a simila
> I don't need that infrastructure for that, I meant just a hack that say for
> OMP_DEFAULT_DEVICE=257 I'd use this hackish device, and store the splay tree
> root and lock in a global var with a comment that that in the future will
> belong into the per-device structure.
Okay, hopefully I would ha
> Trying to dlopen random libraries is bad, so when libgomp dlopens something,
> it better should be a plugin and not something else.
> I'd suggest that the name should be matching libgomp-plugin-*.so.1 or
> similar wildcard.
Ok, sounds reasonable.
> Why? If this is the plugin stuff, then IMNSHO
Hi Jakub,
I continued playing with plugins for libgomp, and I have several questions
regarding that:
1) Would it be ok, at least for the beginning, if we'd look for plugins in a
folder, specified by some environment variable? A plugin would be considered
as suitable, if it's named "*.so" and if d
Hi Thomas,
> The idea, as we discussed it at the GNU Tools Cauldron's Acceleration
> BoF, is that the host program (for at least some acceleration devices)
> will be responsible for loading the acceleration device's code to the
> device, using some support library that is specific to each accelera
> > Oh, if we just link the target binary as a data section into the host
> > binary, then I see no problems in that, it seems absolutely feasible
> > with the existing infrastructure. I just thought (seemingly it was
> > incorrect) that we're speaking about linking of target code with the
> > hos
> I'd go with .gnu.target_lto* names (i.e. s/.gnu.lto/.gnu.target_lto/
> on the existing LTO section names if they are for the accelerator rather
> than host).
I guess that now we could go with any naming, as it's far from being
finalized.
> I really have almost zero experience with LTO, but I don
Hi guys,
Let's continue this discussion.
Summing up what was said above, I think we need following changes in
LTO-infrastructure to enable offloading:
* [in lto_plugin] claim files with .openmp (or whatever
name) sections along with files containing .lto sections, as we do now
* [in lto_plugin
> Perhaps instead of passing array of { void *hostaddr; size_t length; char
> kind; }
> and length we could pass 3 arrays and length (the same for all of them).
> I can see 2 advantages of doing that:
> 1) the sizes are often constant and the kinds are always constant, so
> we could often allocate
> What I meant was just that if you call GOMP_target with
> num_descs N, then the structure will look like:
> struct .omp_target_data
> {
> sometype0 *var0;
> sometype1 *var1;
> ...
> sometypeNminus1 *varNminus1;
> };
> so pretty much the runtime will call the target routine with address of
);
how would FN_NAME, called on the target, figure out where to find its
arguments (as TARGET_ADDRS contains all mapped at runtime addresses)?
---
Thanks, Michael
On 26 Aug 16:11, Jakub Jelinek wrote:
> On Mon, Aug 26, 2013 at 05:29:36PM +0400, Michael V. Zolotukhin wrote:
> > > Nope, there
_in->c[i];
> }
>
> Just look what omplower pass does for normal OpenMP code, say
> #pragma omp parallel, task etc.
Actually, I meant the same (but probably used a poor notation for this
as well) - I like the idea of having similar approaches in 'pragma
target' and 'prag
greed.
> As specs are target specific, I'm afraid you'll need to be looking for
> the gcc driver for the target, not lto1 binary.
I think I didn't get it. Could you explain this point? What are the specs
here?
> Configure could record the names, or you could scan a di
similar problem - there we would need to find out
plugins names from somewhere. The difference is that libgomp would
always iterate through all plugins independently on compiler options,
but even with this I currently have no idea of how to populate list of
plugins names (I suppose, this should be don
calls to libgomp.so, which
is target-independent (i.e. it's host-specific). It should be able to
call plugins for all three targets, so in functions like
gomp_offload_available it probably would iterate through all available
plugins, asking for device status and the code availability. Th
viable, or should it be done in some other way?
--
---
Best regards,
Michael V. Zolotukhin,
Software Engineer
Intel Corporation.
19 matches
Mail list logo
