Hi!
On Thu, 17 Jul 2014 15:35:36 +0200, Jakub Jelinek wrote:
> On Thu, Jul 17, 2014 at 03:09:32PM +0200, Thomas Schwinge wrote:
> > > But I'm not yet sure how we could use this to tie the libgomp plugin
> > > search path to the location of libgomp.so... Especially, given that the
> > > location
On Thu, Jul 17, 2014 at 03:09:32PM +0200, Thomas Schwinge wrote:
> > But I'm not yet sure how we could use this to tie the libgomp plugin
> > search path to the location of libgomp.so... Especially, given that the
> > location of libgomp.so during compilation need not match the location
> > during
Hi!
On Thu, 17 Jul 2014 14:58:04 +0200, I wrote:
> On Thu, 17 Jul 2014 14:37:12 +0200, Jakub Jelinek wrote:
> > On Thu, Jul 17, 2014 at 04:30:15PM +0400, Ilya Verbin wrote:
> > > 2014-07-17 11:51 GMT+04:00 Thomas Schwinge :
> > > >> + plugin_path = getenv ("LIBGOMP_PLUGIN_PATH");
> > > >
> > > >
Hi!
On Thu, 17 Jul 2014 14:37:12 +0200, Jakub Jelinek wrote:
> On Thu, Jul 17, 2014 at 04:30:15PM +0400, Ilya Verbin wrote:
> > 2014-07-17 11:51 GMT+04:00 Thomas Schwinge :
> > >> + plugin_path = getenv ("LIBGOMP_PLUGIN_PATH");
> > >
> > > What is the benefit of making this an environment variab
On Thu, Jul 17, 2014 at 04:30:15PM +0400, Ilya Verbin wrote:
> 2014-07-17 11:51 GMT+04:00 Thomas Schwinge :
> >> + plugin_path = getenv ("LIBGOMP_PLUGIN_PATH");
> >
> > What is the benefit of making this an environment variable that the user
> > set to set, LIBGOMP_PLUGIN_PATH, as opposed to hard-
2014-07-17 11:51 GMT+04:00 Thomas Schwinge :
>> + plugin_path = getenv ("LIBGOMP_PLUGIN_PATH");
>
> What is the benefit of making this an environment variable that the user
> set to set, LIBGOMP_PLUGIN_PATH, as opposed to hard-coding it to
> somewhere inside the GCC installation directory ([...]/l
Hi!
On Fri, 13 Sep 2013 15:29:30 +0400, "Michael V. Zolotukhin"
wrote:
> [patch for adding plugins support in libgomp]
One question:
> --- a/libgomp/target.c
> +++ b/libgomp/target.c
> +/* This functions scans folder, specified in environment variable
> + LIBGOMP_PLUGIN_PATH, and loads all
On Mon, Feb 17, 2014 at 07:59:16PM +0400, Ilya Verbin wrote:
> On 14 Feb 16:43, Jakub Jelinek wrote:
> > So, perhaps we should just stop for now oring the copyfrom in and just use
> > the copyfrom from the very first mapping only, and wait for what the
> > committee
> > actually agrees on.
> >
>
On 14 Feb 16:43, Jakub Jelinek wrote:
> So, perhaps we should just stop for now oring the copyfrom in and just use
> the copyfrom from the very first mapping only, and wait for what the committee
> actually agrees on.
>
> Jakub
Like this?
@@ -171,11 +171,16 @@ gomp_map_vars_existing (splay
On 02/14/2014 07:43 AM, Jakub Jelinek wrote:
> So, perhaps we should just stop for now oring the copyfrom in and just use
> the copyfrom from the very first mapping only, and wait for what the committee
> actually agrees on.
>
> Richard, your thoughts on this?
I think stopping the or'ing until th
On Fri, Feb 14, 2014 at 07:24:16PM +0400, Ilya Verbin wrote:
> 2014-01-31 22:03 GMT+04:00 Jakub Jelinek :
> > Implicit map(tofrom: a) on #pragma omp target is what the standard
> > requires, so I don't see a bug on the compiler side.
> > Jakub
>
> There is an exception in the standard (pag
2014-01-31 22:03 GMT+04:00 Jakub Jelinek :
> Implicit map(tofrom: a) on #pragma omp target is what the standard
> requires, so I don't see a bug on the compiler side.
> Jakub
There is an exception in the standard (page 177, lines 17-21):
> If a corresponding list item of the original list
2014-01-31 Jakub Jelinek :
> I'd suggest just using map(tofrom: a[0:N]) also on the #pragma omp target,
> then it is clear what should happen.
>
> Jakub
I agree that this will be clearer. But there is an example #49.1 in
the document [1] with the same case. And it crashes because the
poi
On Fri, Jan 31, 2014 at 09:18:33PM +0400, Ilya Verbin wrote:
> Looks like there is a bug (in GOMP_target lowering? or in
> gomp_map_vars_existing?)
> The reproducer:
>
> #define N 1000
>
> void foo ()
> {
> int *a = malloc (N * sizeof (int));
> printf ("1: %p\n", a);
> #pragma omp target da
Looks like there is a bug (in GOMP_target lowering? or in
gomp_map_vars_existing?)
The reproducer:
#define N 1000
void foo ()
{
int *a = malloc (N * sizeof (int));
printf ("1: %p\n", a);
#pragma omp target data map(tofrom: a[0:N])
{
printf ("2: %p\n", a);
#pragma omp target
{
On Mon, Oct 28, 2013 at 02:42:37PM +0400, Ilya Verbin wrote:
> We have a MIC offload runtime library (liboffload), which is an abstraction
> over
> COI. Currently it is a part of ICC, but there are plans of open sourcing it.
> However, liboffload requires somewhat different tables comparing to wh
Hi Jakub,
We have a MIC offload runtime library (liboffload), which is an abstraction over
COI. Currently it is a part of ICC, but there are plans of open sourcing it.
However, liboffload requires somewhat different tables comparing to what we have
agreed on. The liboffload tables serve to assoc
On Tue, Sep 17, 2013 at 04:04:54PM +0400, Michael V. Zolotukhin wrote:
> > ... and the first GOMP_target,
> > GOMP_target_data or GOMP_target_update from a particular shared library or
> > binary (all of them will have __OPENMP_TARGET__ weak hidden symbol as one of
> > the arguments) offloads the e
> > 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
On Fri, Sep 13, 2013 at 01:34:43PM +0400, Michael Zolotukhin wrote:
> 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
On Fri, Sep 13, 2013 at 02:36:14PM +0200, Jakub Jelinek wrote:
> FYI, I'm attaching a WIP patch with the splay tree stuff, debugging
> target-1.c with OMP_DEFAULT_DEVICE=257 right now (with all tgtv related
> stuff removed), but hitting some error regarding OMP_CLAUSE_MAP_POINTER
> reallocation, su
Hi,
I'm working on dumping gimple for "omp pragma target" stuff into
gnu.target_lto_ sections.
I've tried to reuse current lto infrastructure as much as possible.
Could you please take a look at attached patch?
gomp_out.patch
Description: Binary data
On Fri, Sep 13, 2013 at 05:11:09PM +0400, Michael V. Zolotukhin wrote:
> > FYI, I'm attaching a WIP patch with the splay tree stuff.
> Thanks, I'll take a look. By the way, isn't it better to move splay-tree
> implementation to a separate file?
As it is just a few routines, heavily modified from
> 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
On Fri, Sep 13, 2013 at 03:29:30PM +0400, Michael V. Zolotukhin wrote:
> 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 pro
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
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
Hello,
Adding Richard who might want to take a look at LTO stuff.
--
Thanks, K
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.
We might publish it to a GCC wiki, if it is ok. And later we could fill it with
more details if n
On Tue, Sep 10, 2013 at 07:30:53PM +0400, Michael V. Zolotukhin wrote:
> > > 4) We'll need to store some information about available devices:
> > > - a search tree with data about mapping
> >
> > For the search tree, I was going to actually implement it myself, but got
> > interrupted this week
> 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
On Tue, Sep 10, 2013 at 07:01:26PM +0400, Michael V. Zolotukhin wrote:
> 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?
On Wed, Aug 28, 2013 at 1:37 PM, Jakub Jelinek wrote:
> On Wed, Aug 28, 2013 at 01:21:53PM +0200, Richard Biener wrote:
>> My thought was that we need to have control over scheduling and thus have
>> a single runtime to be able to execute the following in parallel on the
>> accelerator and the CPU
> 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
On Wed, 2013-08-28 at 13:21 +0200, Richard Biener wrote:
> On Wed, Aug 28, 2013 at 1:06 PM, 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.
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 t
On Wed, Aug 28, 2013 at 01:21:53PM +0200, Richard Biener wrote:
> My thought was that we need to have control over scheduling and thus have
> a single runtime to be able to execute the following in parallel on the
> accelerator and the CPU:
>
> #pragma omp parallel
> {
> #pragma omp target
>fo
On Wed, Aug 28, 2013 at 1:06 PM, Jakub Jelinek wrote:
> On Wed, Aug 28, 2013 at 12:39:00PM +0200, Richard Biener wrote:
>> > So, here is the original code:
>> >
>> > #pragma omp declare target
>> > int v = 6;
>> > int tgt ()
>> > {
>> > #pragma omp atomic update
>> > v++;
>> >
On Wed, Aug 28, 2013 at 12:39:00PM +0200, Richard Biener wrote:
> > So, here is the original code:
> >
> > #pragma omp declare target
> > int v = 6;
> > int tgt ()
> > {
> > #pragma omp atomic update
> > v++;
> > return 0;
> > }
> > #pragma omp end declare target
> >
> >
On Mon, Aug 26, 2013 at 1:59 PM, Michael V. Zolotukhin
wrote:
>> No need for the device and handler IMHO, each vector would correspond to
>> one function call (GOMP_target, GOMP_target_data or GOMP_target_update)
>> and all those calls would be called with device id.
> Probably yes.
>
>> Let's tal
On Tue, Aug 27, 2013 at 03:55:38PM +0400, Michael V. Zolotukhin wrote:
> > 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 *var
> 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
On Tue, Aug 27, 2013 at 03:26:09PM +0400, Michael V. Zolotukhin wrote:
> > Anyway, the GOMP_target_data implementation and part of GOMP_target would
> > be something along the lines of following pseudocode:
> >
> > device_data = lookup_device_id (device_id);
> > ...
> Thanks, I've seen that simila
Hi Jakub,
> Anyway, the GOMP_target_data implementation and part of GOMP_target would
> be something along the lines of following pseudocode:
>
> device_data = lookup_device_id (device_id);
> ...
Thanks, I've seen that similarly. But the problem with passing
arguments to the target is still open
On Mon, Aug 26, 2013 at 05:29:36PM +0400, Michael V. Zolotukhin wrote:
> > Nope, there is only one target data pragma, so you would use here just:
> >
> > struct data_descriptor data_desc2[2] = { ... };
> > GOMP_target (-1, bar.omp_fn.1, "bar.omp_fn.1", data_desc2, 2);
> This 'pragma target' i
> Actually, not two versions of those during the compilation, you have
> just one v and one tgt, both have __attribute__(("omp declare target"))
> on them (note, you can't specify that attribute manually).
> And just when streaming into .gnu.target_lto_* sections you only stream
> everything that h
On Mon, Aug 26, 2013 at 03:59:11PM +0400, Michael V. Zolotukhin wrote:
> As I currently see it, the given code would be expanded to something like
> this:
>
> // Create two versions of V: for host and for target
> int v;
> int v_target __attribute(target);
>
> // The same for TGT function
> No need for the device and handler IMHO, each vector would correspond to
> one function call (GOMP_target, GOMP_target_data or GOMP_target_update)
> and all those calls would be called with device id.
Probably yes.
> Let's talk about some concrete example (though, I see the gimplifier
> doesn't
On Fri, Aug 23, 2013 at 07:30:52PM +0400, Michael V. Zolotukhin wrote:
> That makes sense. We could maintain a vector of descriptors for each
> encountered MAP clause and push to and pop from it when needed (when
> e.g. new mapping is encountered inside 'pragma omp target data'). The
> desciptor
> The single call approach would just be passed array of control structures
> that would describe each of the MAP clauses, and you'd simply loop over
> them; the standard requires that if some object is already mapped into the
> device, then nothing is performed (well, target update is an exception
On Fri, Aug 23, 2013 at 01:28:10PM +0400, Michael V. Zolotukhin wrote:
> Sure, I used '#pragma omp target' just for a simple example. The
> question about '#pragma omp target data' is still open. As far as I
> understand, all three of the pragmas could require data marshalling (but
> not necessar
> Roughly. We have 3 directives here,
> #pragma omp target
> #pragma omp target data
> #pragma omp target update
> and all of them have various clauses, some that are allowed at most once
> (e.g. the device clause, if clause) and others that can be used many times
> (the data movement clauses).
>
On Thu, Aug 22, 2013 at 06:08:10PM +0400, Michael V. Zolotukhin wrote:
> We're working on design for offloading support in GCC (part of OpenMP4), and I
> have a question regarding libgomp part.
>
> Suppose we expand '#pragma omp target' like we expand '#pragma omp parallel',
> i.e. the compiler ex
Hi,
We're working on design for offloading support in GCC (part of OpenMP4), and I
have a question regarding libgomp part.
Suppose we expand '#pragma omp target' like we expand '#pragma omp parallel',
i.e. the compiler expands the following code:
#pragma omp target
{
body;
}
to this:
v
57 matches
Mail list logo
