Hi!
On 2019-12-07T15:22:33+0100, I wrote:
> [...] propose the attached patch
> adding a safeguard [...]
See attached "Assert in 'libgomp/target.c:gomp_unmap_vars_internal' that
we're not unmapping 'tgt' while it's still in use"; committed to trunk in
r279534.
Grüße
Thomas
From 7c82035afd9b01
Hi!
This is from very early days of libgomp offloading support:
On 2013-09-14T21:29:56+0200, Jakub Jelinek wrote:
> --- libgomp/target.c.jj 2013-09-09 17:41:02.290429613 +0200
> +++ libgomp/target.c 2013-09-13 16:41:24.514770386 +0200
> +static void
> +gomp_unmap_tgt (struct target_mem_d
Hi!
On Fri, 13 Sep 2013 15:29:30 +0400, "Michael V. Zolotukhin"
wrote:
> Here is the first patch for adding plugins support in libgomp - could you
> please
> take a look at it?
> --- a/libgomp/target.c
> +++ b/libgomp/target.c
> +/* This structure describes accelerator device.
> + It contai
> No. If you insert 1 to 100 into a splay tree in ascending order (that will
> give you a totally unbalanced tree), and then lookup 1 to 100 in the
> ascending order again, then the lookup of 1 will be expensive (100
> comparisons), but then for each following lookup it
> will cost just 2 comparis
On Mon, Sep 16, 2013 at 11:15:16AM +0400, Michael V. Zolotukhin wrote:
> > Yes, splay tree can get totally unbalanced and you can have a linear lookup
> > time, the O(log n) lookup time is amortized. But, if you e.g. really do
> > lookup sorted keys (which is not given, the compiler puts vars into
> Yes, splay tree can get totally unbalanced and you can have a linear lookup
> time, the O(log n) lookup time is amortized. But, if you e.g. really do
> lookup sorted keys (which is not given, the compiler puts vars into the
> clauses based on the user order or in the order references to those va
On Sun, Sep 15, 2013 at 07:41:24PM +0400, Michael V. Zolotukhin wrote:
> > Libgomp will start N-1 new threads, and all of them would want to look up
> > mappings for i1,i2,...iK in the splay tree. The first one wouldn't find
> > anything and would map and insert all the values to the tree. But th
> Libgomp will start N-1 new threads, and all of them would want to look up
> mappings for i1,i2,...iK in the splay tree. The first one wouldn't find
> anything and would map and insert all the values to the tree. But the
> following
> ones would look-up these addresses in the exactly same order
Hi Jakub,
This patch looks ok for me in general, but I am a bit worried about using
splay-trees. Couldn't we end up with their worst case linear performance
instead desired log?
Imagine the following scenario:
#pragma parallel ... // to produce N-threads
{
# pragma target map (i1, i2, ...i
On Fri, Sep 13, 2013 at 05:41:03PM +0200, Marek Polacek wrote:
> On Fri, Sep 13, 2013 at 05:35:27PM +0200, Jakub Jelinek wrote:
> > On Fri, Sep 13, 2013 at 03:15:56PM +0200, Jakub Jelinek wrote:
> > > On Fri, Sep 13, 2013 at 05:11:09PM +0400, Michael V. Zolotukhin wrote:
> > > > > FYI, I'm attachin
On Fri, Sep 13, 2013 at 05:35:27PM +0200, Jakub Jelinek wrote:
> On Fri, Sep 13, 2013 at 03:15:56PM +0200, Jakub Jelinek wrote:
> > 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
On Fri, Sep 13, 2013 at 03:15:56PM +0200, Jakub Jelinek wrote:
> 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
12 matches
Mail list logo
