From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39276 invoked by alias); 21 Jul 2015 11:44:24 -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 39250 invoked by uid 89); 21 Jul 2015 11:44:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 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; Tue, 21 Jul 2015 11:44:18 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1ZHVy3-0000Of-0T from Tom_deVries@mentor.com for gcc-patches@gcc.gnu.org; Tue, 21 Jul 2015 04:44:15 -0700 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.3.224.2; Tue, 21 Jul 2015 12:44:12 +0100 Message-ID: <55AE3082.1020507@mentor.com> Date: Tue, 21 Jul 2015 12:07:00 -0000 From: Tom de Vries User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Thomas Schwinge , Nathan Sidwell CC: GCC Patches Subject: Re: [gomp4] remove kernel-specific launch References: <55AB97C0.4080303@acm.org> <87y4ibubyj.fsf@kepler.schwinge.homeip.net> <55AC11B1.4020407@acm.org> <55ACC568.8060503@mentor.com> <87twsxu821.fsf@kepler.schwinge.homeip.net> In-Reply-To: <87twsxu821.fsf@kepler.schwinge.homeip.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg01741.txt.bz2 On 21/07/15 12:19, Thomas Schwinge wrote: > Hi! > > Thanks for the cleanup! > > On Mon, 20 Jul 2015 11:54:48 +0200, Tom de Vries wrote: >> On 19/07/15 23:08, Nathan Sidwell wrote: >>> On 07/19/15 16:30, Thomas Schwinge wrote: >>>> Does it make sense then to rename GOACC_kernels_internal to >>>> GOACC_kernels? > >>> [...] perhaps it should be an internal fn? IIUC those >>> are for pseudo-funcs that should be converted to something else before >>> the end of compilation. >> >> Turning it into an internal fn will make it harder to convert a >> GOACC_kernels_internal call into a GOACC_parallel call, which we're >> doing here in omp-low.c: >> ... >> tree fndecl = builtin_decl_explicit (BUILT_IN_GOACC_PARALLEL); >> gimple_call_set_fndecl (call, fndecl); >> gimple_call_set_fntype (call, TREE_TYPE (fndecl)); >> gimple_call_reset_alias_info (call); >> ... > > ..., and also a similar transformation in gcc/tree-parloops.c, I think, That's not a similar transformation. The GOACC_kernels_internal call is removed. > which I've not been too fond of ;-) anyway, because of: > >> --- a/gcc/tree-parloops.c >> +++ b/gcc/tree-parloops.c >> @@ -2045,11 +2045,12 @@ create_parallel_loop (struct loop *loop, tree loop_fn, tree data, >> } >> else >> { >> - /* Create oacc parallel pragma based on oacc kernels pragma. */ >> + /* Create oacc parallel pragma based on oacc kernels pragma and >> + GOAC_kernels_internal call. */ >> gomp_target *kernels = as_a (gsi_stmt (gsi)); >> >> gsi_prev (&gsi); >> - gcall *goacc_kernels = as_a (gsi_stmt (gsi)); >> + gcall *goacc_kernels_internal = as_a (gsi_stmt (gsi)); >> >> tree clauses = gimple_omp_target_clauses (kernels); >> /* FIXME: We need a more intelligent mapping onto vector, gangs, >> @@ -2070,7 +2071,8 @@ create_parallel_loop (struct loop *loop, tree loop_fn, tree data, >> gimple_omp_target_set_child_fn (stmt, child_fn); >> tree data_arg = gimple_omp_target_data_arg (kernels); >> gimple_omp_target_set_data_arg (stmt, data_arg); >> - tree ganglocal_size = gimple_call_arg (goacc_kernels, /* TODO */ 9); >> + tree ganglocal_size >> + = gimple_call_arg (goacc_kernels_internal, /* TODO */ 9); >> gimple_omp_target_set_ganglocal_size (stmt, ganglocal_size); > > ... this "clumsy" argument copying. > > As I understand it, there is an implicit/non-obvious requirement that the > GOACC_kernels_internal and GOACC_parallel function/built-in signatures > match? It's not a hard requirement, but it's probably a good idea. Thanks, - Tom