From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114189 invoked by alias); 13 Nov 2015 16:37:49 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 114173 invoked by uid 89); 13 Nov 2015 16:37:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-io0-f172.google.com Received: from mail-io0-f172.google.com (HELO mail-io0-f172.google.com) (209.85.223.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 13 Nov 2015 16:37:47 +0000 Received: by ioc74 with SMTP id 74so102585084ioc.2 for ; Fri, 13 Nov 2015 08:37:45 -0800 (PST) X-Received: by 10.107.167.9 with SMTP id q9mr12845112ioe.84.1447432665605; Fri, 13 Nov 2015 08:37:45 -0800 (PST) Received: from msticlxl57.ims.intel.com (jfdmzpr03-ext.jf.intel.com. [134.134.139.72]) by smtp.gmail.com with ESMTPSA id kb7sm1600717igb.11.2015.11.13.08.37.42 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2015 08:37:45 -0800 (PST) Date: Fri, 13 Nov 2015 16:37:00 -0000 From: Ilya Verbin To: Jakub Jelinek Cc: Aldy Hernandez , gcc-patches@gcc.gnu.org, Kirill Yukhin , Thomas Schwinge , Alexander Monakov , Martin Jambor Subject: Re: [gomp4.5] depend nowait support for target Message-ID: <20151113163717.GA28000@msticlxl57.ims.intel.com> References: <20150908092014.GA1847@tucnak.redhat.com> <20151002192801.GA24765@msticlxl57.ims.intel.com> <20151015140156.GE478@tucnak.redhat.com> <20151019194754.GB1855@msticlxl57.ims.intel.com> <20151111165222.GL5675@tucnak.redhat.com> <20151112174509.GG5675@tucnak.redhat.com> <20151112205133.GC4917@msticlxl57.ims.intel.com> <20151113101841.GL5675@tucnak.redhat.com> <20151113151150.GQ5675@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151113151150.GQ5675@tucnak.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg01740.txt.bz2 On Fri, Nov 13, 2015 at 16:11:50 +0100, Jakub Jelinek wrote: > On Fri, Nov 13, 2015 at 11:18:41AM +0100, Jakub Jelinek wrote: > > For the offloading case, I actually see a problematic spot, namely that > > GOMP_PLUGIN_target_task_completion could finish too early, and get the > > task_lock before the thread that run the gomp_target_task_fn doing map_vars > > + async_run for it. Bet I need to add further ttask state kinds and deal > > with that case (so GOMP_PLUGIN_target_task_completion would just take the > > task lock and tweak ttask state if it has not been added to the queues > > yet). > > Plus I think I want to improve the case where we are not waiting, in > > gomp_create_target_task if not waiting for dependencies actually schedule > > manually the gomp_target_task_fn. > > These two have been resolved, plus target-34.c issue resolved too (the bug > was that I've been too lazy and just put target-33.c test into #pragma omp > parallel #pragma omp single, but that is invalid OpenMP, as single is a > worksharing region and #pragma omp barrier may not be encountered in such a > region. Fixed by rewriting the testcase. > > So here is a full patch that passes for me both non-offloading and > offloading, OMP_NUM_THREADS=16 (implicit on my box) as well as > OMP_NUM_THREADS=1 (explicit). I've incorporated your incremental patch. > > One option to avoid the static variable would be to pass two pointers > instead of one (async_data), one would be the callback function pointer, > another argument to it. Or another possibility would be to say that > the async_data argument the plugin passes to liboffloadmic would be > pointer to structure, holding a function pointer (completion callback) > and the data pointer to pass to it, and then the plugin would just > GOMP_PLUGIN_malloc 2 * sizeof (void *) for it, fill it in and > register some function in itself that would call the > GOMP_PLUGIN_target_task_completion with the second structure element > as argument and then free the structure pointer. I don't know which interface to implement to maintain compatibility in the future. Anyway, currently it's impossible that a process will use the same liboffloadmic for 2 different offloading paths (say GCC's in exec and ICC's in a dso), because in fact GCC's and ICC's libraries are not the same. First of all, they have different names: liboffloadmic in GCC and just liboffload in ICC. And most importantly, ICC's version contains some references to libiomp5, which were removed form GCC's version. In theory, we want to use one library with all compilers, but I'm not sure when it will be possible. > Do you get still crashes on any of the testcases with this? No, all tests now pass using emul. I'll report when I have any results on HW. Thanks, -- Ilya