From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id BF1F13858C3A for ; Mon, 26 Jul 2021 11:38:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BF1F13858C3A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: mWPWBA7dDQO5tG7AAKWH6GeB7hecq02sVUMqm+4oopwKWaOi5xOjGee7cE/D9g4Kh74FwOuabx 3M8bcr7BXf4cgwCwa07I25Ei3cvnlOhe7yao8xpDrrWbas0/3i3xagfGhpATgjhttMzWT/01/Q oVVL+5OVnE+BGyUS6oIpL0JNuSxCpFOYRlRIMX1ugbHkZeiO2rQbbDmCUsf1A5P9NXhPxWN7Ef MlrfofPuRF+0yKzjuqVbnef5rm/eidxdErZCRDBcRjQ9QRUPhHXfmY/roC7hg3QIYtZetVVlHO YVuIRwgCuCG/lSvz22FjWjFb X-IronPort-AV: E=Sophos;i="5.84,270,1620720000"; d="scan'208";a="63911668" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 26 Jul 2021 03:38:31 -0800 IronPort-SDR: PDnNFVzLNIcLPFK4TagkGkcmksjwF3egkgcgQbfBSTrbAZP9u228l4HZLZzDV7tmGL812nA7uV bj/CeJvhmEiwzGnTAJvfxZB9XZCJ21pApt6Gfe1vpg9BHQSfm2R51uzMpUCiyGEjR20xqGrWSz 6oyIMkcZgNFsi3CXV0+eHjDRlViER4SN+jbhmACK54xWZK4iF30AI6H26XZM32Wr8clOPdA/ya JMGAKsDoJdraUEIYA3zPj0nnwH2c2hDibZjmwzOYX4MDzfu96jjm/quuch+hZ7mCDNagJC72wY Lc8= Subject: Re: [WIP, OpenMP] OpenMP metadirectives support From: Kwok Cheung Yeung To: GCC Patches , Jakub Jelinek References: <8d413974-0068-3a31-6ae5-d36c1be06d06@codesourcery.com> Message-ID: Date: Mon, 26 Jul 2021 12:38:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <8d413974-0068-3a31-6ae5-d36c1be06d06@codesourcery.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-09.mgc.mentorg.com (139.181.222.9) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, BODY_8BITS, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 11:38:34 -0000 Ping? Does anyone have any opinions on how this issue should be resolved? On 09/07/2021 12:16 pm, Kwok Cheung Yeung wrote: > 3) In the OpenMP examples (version 5.0.1), section 9.7, the example > metadirective.3.c does not work as expected. > > #pragma omp declare target > void exp_pi_diff(double *d, double my_pi){ >    #pragma omp metadirective \ >                when( construct={target}: distribute parallel for ) \ >                default( parallel for simd) > ... > int main() > { >    ... >    #pragma omp target teams map(tofrom: d[0:N]) >    exp_pi_diff(d,my_pi); >    ... >    exp_pi_diff(d,my_pi); > > In the first call to exp_pi_diff in an '#pragma omp target' construct, the > metadirective is expected to expand to 'distribute parallel for', but in the > second (without the '#pragma omp target'), it should expand to 'parallel for simd'. > > During OMP expansion of the 'omp target', it creates a child function that calls > exp_pi_diff: > > __attribute__((omp target entrypoint)) > void main._omp_fn.0 (const struct .omp_data_t.12 & restrict .omp_data_i) > { >   ... >   : >   __builtin_GOMP_teams (0, 0); >   exp_pi_diff (d.13, my_pi); > > This is not a problem on the offload compiler (since by definition its copy of > exp_pi_diff must be in a 'target'), but if the host device is used, the same > version of exp_pi_diff is called in both target and non-target contexts. > > What would be the best way to solve this? Offhand, I can think of two solutions: > > (a) Recursively go through all functions that can be reached via a target region > and create clones for each, redirecting all function calls in the clones to the > new cloned versions. Resolve the metadirectives in the clones and originals > separately. > Maybe this could be done at the same time as when marking functions implicitly 'declare target'? It seems a lot of work for one special case though... > (b) Make the construct selector a dynamic selector when OpenMP 5.1 metadirective > support is implemented. Keep track of the current construct list every time an > OpenMP construct is entered or exited, and make the decision at runtime. > I think this would be easier to implement at runtime (assuming that the infrastructure for OpenMP 5.1 was already in place) since this a host-side issue, but it probably goes against the intent of the specification, given that the 'construct' selector set appeared in the 5.0 specification before dynamic replacements became available. Thanks Kwok