From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10534 invoked by alias); 12 Nov 2014 11:03:40 -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 10524 invoked by uid 89); 12 Nov 2014 11:03:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Nov 2014 11:03:38 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XoVi2-0001Gl-HS from Julian_Brown@mentor.com ; Wed, 12 Nov 2014 03:03:34 -0800 Received: from octopus (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.181.6; Wed, 12 Nov 2014 11:03:32 +0000 Date: Wed, 12 Nov 2014 11:06:00 -0000 From: Julian Brown To: Jakub Jelinek CC: , Thomas Schwinge , Ilya Verbin Subject: Re: [PATCH 1/5] OpenACC 2.0 support for libgomp - OpenACC runtime, NVidia PTX/CUDA plugin (repost) Message-ID: <20141112110326.5b2525c3@octopus> In-Reply-To: <20141112100626.GP5026@tucnak.redhat.com> References: <20140923191931.2177e60f@octopus> <20141111135323.29e0f27b@octopus> <20141112100626.GP5026@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg01172.txt.bz2 On Wed, 12 Nov 2014 11:06:26 +0100 Jakub Jelinek wrote: > On Tue, Nov 11, 2014 at 01:53:23PM +0000, Julian Brown wrote: > > A few OpenMP tests fail with the new host_nonshm plugin (with > > failures of the form "libgomp: Trying to update > > [0x605820..0x605824) object that is not mapped"), probably because > > of middle-end bugs. I haven't investigated those in detail. > > Depends how exactly your host_nonshm plugin works. A few tests in the > testsuite use #pragma omp declare target variables, so if host_nonshm > plugin is something like I had on the gomp-4_0-branch initially as > hackish device 257, where code is run on the host, and map directives > simply malloc/free host memory and memcpy stuff around, then without > extra work the #pragma omp declare target variables indeed can't work. > You'd either need to support a strange partially shared memory model, > where #pragma omp declare target variables would be shared (you'd > still need to populate the mapping data structures with those vars > and identity map them), or not so conforming model where you'd map > them on entering the target regions if they aren't mapped yet (the > thing is that then if the variables are changed on the host in > between the start of the program and the target region, you'd use the > changed values instead the values they were originally assigned), or > map them in some constructor (but, how would you know if a > host_nonshm plugin is going to be used in the future). Thanks for the review! I'll work on addressing your comments. Your characterization of the host_nonshm plugin sounds accurate, but OOI, what does the Intel MIC plugin do differently that means it is not subject to the same problem with target variables? > One can always use the intelmicemul plugin to test nonshared-memory > stuff without any HW (provided the host is x86_64/i686), so do we > really need host_nonshm plugin? It might still be useful for testing (non-shm) OpenACC without hardware, I guess (or for pedagogical purposes) -- perhaps we could remove the TARGET_CAP_OPENMP_400 flag, if that's not expected to work. Julian