From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 0F7AE3857C5A for ; Wed, 2 Mar 2022 16:11:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0F7AE3857C5A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=mentor.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.90,149,1643702400"; d="scan'208";a="72610319" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 02 Mar 2022 08:11:25 -0800 IronPort-SDR: JVllgVmuOB8NwkjaAjsNyG6UBmyXXaMqm7gvqFpulftN4onxnNGwz7rK2z4in30RXt6oKua0oc R+h3bShRi/sUXaf/53pU2yAkplwVhQA8APT5i9UrGm3YD4eIylvcadH7mQgQLUbqGNNwIsIPex GMlQ2XYrVbs+emmd9l8H5WHZOrSidm9l1psCxKwOJZlQpG9sC5yd+PKmRq57piTdPliTng1iRF atBqOuvD9/0/1OY1OHBdUSRQxOt8hSSYglQK5V4K/MrdYf//d/QPo2nnDuJdRtMcBOpCcykBaN Rvs= From: "Stubbs, Andrew" To: Jakub Jelinek CC: "gcc@gcc.gnu.org" Subject: RE: OpenMP auto-simd Thread-Topic: OpenMP auto-simd Thread-Index: AdguP7ccSXQ1uzq1SFe+HdKUP8TCfwACe7kAAACW6gA= Date: Wed, 2 Mar 2022 16:11:21 +0000 Message-ID: References: <2213264c2c5c467fb491f71051173873@svr-ies-mbx-01.mgc.mentorg.com> In-Reply-To: Accept-Language: en-GB, en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.202.0.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2022 16:11:27 -0000 > -----Original Message----- > From: Jakub Jelinek > Sent: 02 March 2022 15:25 > To: Stubbs, Andrew > Cc: gcc@gcc.gnu.org > Subject: Re: OpenMP auto-simd >=20 > On Wed, Mar 02, 2022 at 03:12:30PM +0000, Stubbs, Andrew wrote: > > Has anyone ever considered having GCC add the "simd" clause to offload = (or > regular) loop nests automatically? > > > > For example, something like "-fomp-auto-simd" would transform "distribu= te > parallel" to "distribute parallel simd" automatically. Loop nests that > already contain "simd" clauses or directives would remain unchanged, most > likely. >=20 > I'm afraid we can't do that, at least not always. The simd has various > restrictions on what can appear inside of the body, etc. and we shouldn't > reject valid code just because we decided to add simd automatically (even= if > the user asked for those through an option). > So, it could be done only if we would do analysis that it is safe to do > that. In the general case there are undoubtedly issues, but I think the restricti= ons listed in the OpenMP document ought to be detectable, for at least the = inline code. Is there one that is too hard, at least during the early passe= s? I anticipate that version 1.0 wouldn't add the directive to regions that= include function calls (unless declared "simd" explicitly, perhaps), altho= ugh that would be nice to have later. For AMD GCN it's always safe to set the "force_vectorize" flag on any given= loop (it's just the same as setting -ftree-vectorize for the whole program= ) given that the vectorizer will simply quietly fail later. For NVPTX this = might be a bigger issue. Is this really such a lost cause? Thanks Andrew P.S. Ideally we'd do this the same way that other toolchains do it, such th= at omp_get_thread_num returns a number in the range 0..1023 rather than 0..= 15 (AMD) or 0..32 (NVPTX) as we do now, but I think that's just impossible = with the current implementation.