From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3567 invoked by alias); 29 Oct 2019 22:57:58 -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 3558 invoked by uid 89); 29 Oct 2019 22:57:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Oct 2019 22:57:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572389875; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0Pa8MySP/ZfIyrj/GSz3YYCcWSS6sqakuQexarUsIrQ=; b=hsqWdK72rQkt/YJiCyM4Appj3Ajn5K0fW6unEAFzBxNmgvjBLduf6TcuGpjcz/TVi7L4Ss RuFabFIuvIHPZf5MQ/4yQUJGVzM8BMMIKHIgqkwv5sG6Ty9tym76xchPH4qdXUONMZseG1 nQZnlQBMkEwh9JqRs0e+S52z+xrS4P0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-84-aJT6n4LaP5-CdwMBK0FrUg-1; Tue, 29 Oct 2019 18:57:50 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9043D5E6; Tue, 29 Oct 2019 22:57:48 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.36.118.135]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1C61E5D6C5; Tue, 29 Oct 2019 22:57:47 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x9TMviQm029095; Tue, 29 Oct 2019 23:57:45 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x9TMveq0023539; Tue, 29 Oct 2019 23:57:40 +0100 Date: Wed, 30 Oct 2019 03:13:00 -0000 From: Jakub Jelinek To: Segher Boessenkool Cc: Richard Biener , Uros Bizjak , Tom de Vries , Martin Jambor , gcc-patches@gcc.gnu.org, Richard Earnshaw , Andreas Krebbel Subject: Re: [RFC PATCH] targetm.omp.device_kind_arch_isa and OpenMP declare variant kind/arch/isa handling Message-ID: <20191029225740.GN4650@tucnak> Reply-To: Jakub Jelinek References: <20191029171531.GI4650@tucnak> <20191029224011.GH28442@gate.crashing.org> MIME-Version: 1.0 In-Reply-To: <20191029224011.GH28442@gate.crashing.org> User-Agent: Mutt/1.11.3 (2019-02-01) X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg02079.txt.bz2 On Tue, Oct 29, 2019 at 05:40:11PM -0500, Segher Boessenkool wrote: > On Tue, Oct 29, 2019 at 06:15:31PM +0100, Jakub Jelinek wrote: > > The standard makes it implementation defined what an arch is and what is > > isa, but I think because there is no selector like target that arch sho= uld > > mostly contain identifiers that match the ABI incompatible stuff (targe= t, > > perhaps whether it is 32-bit or 64-bit, plus endianity where needed etc= .) > > and keep isa to be identifiers for the ISAs, or perhaps where there are= no > > clear ISA names say architecture variants or revisions or similar. > >=20 > > I've only implemented i386 and nvptx so far, will leave the rest to > > port maintainers; would be nice to coordinate what is added a little bit > > with other implementations like LLVM, if they'd be willing to coordinat= e. >=20 > What would this be used for? Can you give some more context? https://www.openmp.org/spec-html/5.0/openmpse11.html#x41-480002.3 OpenMP 5.0 has two directives, declare variant which I'm implementing right now and metadirective, which I'll be working on next stage1. declare variant is a direct call redirection based on context, where one can provide a specialized function implementation for a particular OpenMP construct, compiler implementation, CPU architecture, etc. The metadirective allows specialization of OpenMP pragmas, use this OpenMP = pragma only in some OpenMP context and not in another one, or only on certain architecture, isa, whatever. These actually don't query anything at runtime, it is purely compile time specialization, based on what either the whole translation unit or a particular function are compiled for. > There already are a lot of different ways to get information about the > execution environment you're running on; why is this any better? There is no question of better or worse, it is simply a part of a standard that GCC is trying to implement, like we try to implement all of C++20, we also try to implement all of OpenMP or OpenACC etc. The exact identifiers are implementation defined though, and that is why we need to think of what is reasonable for each target (at least each target where OpenMP is used often, powerpc is certainly one of those). Jakub