From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53675 invoked by alias); 6 Nov 2015 20:35:12 -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 53662 invoked by uid 89); 6 Nov 2015 20:35:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS 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; Fri, 06 Nov 2015 20:35:10 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1Zunj1-0004FC-1E from James_Norris@mentor.com ; Fri, 06 Nov 2015 12:35:07 -0800 Received: from [172.30.80.115] (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.3.224.2; Fri, 6 Nov 2015 12:35:06 -0800 Message-ID: <563D0EF9.7050703@codesourcery.com> Date: Fri, 06 Nov 2015 20:35:00 -0000 From: James Norris User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jakub Jelinek CC: Thomas Schwinge , GCC Patches Subject: Re: [OpenACC] declare directive References: <562FDBF8.1040105@mentor.com> <5638E164.5010207@codesourcery.com> <87611h1zi7.fsf@kepler.schwinge.homeip.net> <563CD07A.3000404@codesourcery.com> <20151106190352.GG5675@tucnak.redhat.com> <20151106192255.GH5675@tucnak.redhat.com> <563D0B03.30406@codesourcery.com> <20151106202841.GL5675@tucnak.redhat.com> In-Reply-To: <20151106202841.GL5675@tucnak.redhat.com> X-TagToolbar-Keys: D20151106143505075 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-11/txt/msg00730.txt.bz2 On 11/06/2015 02:28 PM, Jakub Jelinek wrote: > On Fri, Nov 06, 2015 at 02:18:11PM -0600, James Norris wrote: >> On 11/06/2015 01:22 PM, Jakub Jelinek wrote: >>> On Fri, Nov 06, 2015 at 08:03:52PM +0100, Jakub Jelinek wrote: >>>> What exactly do you want to achieve? Why do you record it >>>> in gimplify_omp_ctx, but then only look at it in gimplify_body? >>>> The way you abuse gimplify_omp_ctx for that is just too ugly. >>>> All the gimplification code expects that when you enter some OpenMP/OpenACC >>>> construct, you create new context if it needs one, then process the body >>>> of the construct, then pop it up. The declare_returns stuff >>>> violates all of this. Do you want to enqueue all the statements >>>> at the end of the body? Then just stick it into some gimple_seq >>>> outside of the gimplify_omp_ctx, and process in there. Or if you >>>> want to process it when leaving some construct, arrange for that. >>> If the unmap operation is supposed to sit where the corresponding variable >>> goes out of scope, supposedly you would need to find out in which bind >>> (gimplify_ctx (not omp!)) the variable is declared and arrange for the >>> statement to be added as a cleanup of that region. >>> If you queue everything to the end of function, I'm afraid with e.g. >>> void foo (void) >>> { >>> { >>> char buf[2048]; >>> #acc declare whatever(buf) >>> // ... >>> } >>> { >>> char buf2[2048]; >>> #acc declare whatever(buf2) >>> // ... >>> } >>> } >>> both vars will be assigned overlapping ranges and you might run into >>> trouble trying to map buf2 while buf is still mapped. >>> >>> Jakub >> Good point. > Perhaps what would work is stick the "exit" clauses you need for automatic > vars in the function inside of some pointer map / hash table / whatever, > and then in gimplify_bind_expr in the > /* Add clobbers for all variables that go out of scope. */ > if if flag_openacc && the pointer_map /hash table has any entries look > up each variable in there and collect the clauses from those vars that go > out of scope, after the loop if any were collected construct the statement > you need prepend it to cleanup (so that it works before restoring VLA memory > and before the clobber stmts). I like that. Thank you again. > > Jakub Jim