From patchwork Tue Feb 20 16:39:39 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tobias Burnus X-Patchwork-Id: 1901575 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=YKI6lV4f; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4TfQ9z25fPz20Qg for ; Wed, 21 Feb 2024 03:40:05 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D70123858D35 for ; Tue, 20 Feb 2024 16:40:03 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id DCC563858D28 for ; Tue, 20 Feb 2024 16:39:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DCC563858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=baylibre.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DCC563858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::433 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708447184; cv=none; b=kWSRVrzjVq09Hp7khaFG5cJ7v1+F0jEquSKM0NoSnzLcYMCDyPfmy3pXEWSntOwHOrQ3l91aiDcnuVDt3rz1nwl9mhK22SGO9+d8x4+fVhv+isFONl4EoFi2W6u4u+q1l3a6jFuVfBc1sNT6R1G1Ju86Wv2d3Ker9mzxzXmvzzM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708447184; c=relaxed/simple; bh=7rGMZj9chjjUxYphUgvigWqH9ovCpn/1p2iPRlsHnAM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=hD9iFqY68GUhH0oplwL05ooSL2zn0FNKXlpilyTG3f8cB1PIbKhiIv/nccLWEcXdFZZU9x5lqXx6CZ6y8N/b317UouT0xMylTpWbfJyk0nyjob17j/6lacij94C4HOa5B0KVc/GCZEk2uyv5u6RbW2LMNxzY0Qw+U1ax9KOtXGk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-33d38c9ca5bso1491327f8f.2 for ; Tue, 20 Feb 2024 08:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1708447180; x=1709051980; darn=gcc.gnu.org; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=uQSnaA7NQMP47q1xouko1MmuSrlcpFLpML1jEMDR/qA=; b=YKI6lV4fH+SpKO4bf0LvyGTG3diEj5VbPxjJyjNr6jl96PXn8UpOnKbUyM7ccckwSc m/p94R5xtx3aMZRVmuMmAtEtr7GU7T5gV7aM8gScLtfPM5YQQXi5simh/o3nUXmUHBKz JPJG4mu0aa7r+JEVIXs4NjhSWtA4Ue1Nx9/UKPw6yPMfFiOvgneTO02G/uxATLUbMLhW IFT9PVcPtANfJgDusfPmpGXJQtuh5fN46hNzdRRbVoOyxgwRBLIgNxBGorswP3DUVznh Xp+D3/hGiQ40v//TPZHip+PKm3rT9dTLKqrcm+4tYdZTSjtrPpuFwr6R/09J5IgAGSTY qw/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708447180; x=1709051980; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uQSnaA7NQMP47q1xouko1MmuSrlcpFLpML1jEMDR/qA=; b=KO183n+NRwIdc0TeIuCmzYiuK2HwgxjbPNxNlWi2AXw5XVskPzp0Bwdd9NYrVuYmyY LlGZUk5T4DuXx1ehesyY7w4aZkXXutbouQEPZzFPbs7OD6fOzjnU5TjdQUQyPGgSfkO5 gr+FEGapBC0LjbYarLoVcJnKO3CGUTycWbmDq3sPwZAyHvTYQ2El4VsASboHR1KAY/cc eyfXZPCHmyv0F93rtd/19EjjWRqpQZnRQerF3Y6LNv+AH5BCtYuuZUSQQxxW3TdDm8wE jtzP4ErwkCwbYbY2bJln41rsD4PaweYRWc4AAQdRn9FTDPhIB+2IEfnmlVRx8IXLJh83 5aWw== X-Gm-Message-State: AOJu0YxyVERwdz7G/Zg7teoyMBEI/H9ow2TECXALqAoh57uPhhmuOOD1 hMlulI2firYUOnQ9eGqmpJWQ9nb/O5fZill0tBHIUfOw03L7cZepIhiiyoSj/u4UMx4bcVR4R4R 9h68= X-Google-Smtp-Source: AGHT+IH6fp6zd4gtq4gy3fvlhRV1j6LLaPlfqvzK2Nli/chA/gBwM4sLst+wAqfG21GRAuRPF4T5XQ== X-Received: by 2002:a5d:5552:0:b0:33d:3695:5880 with SMTP id g18-20020a5d5552000000b0033d36955880mr5709824wrw.48.1708447180533; Tue, 20 Feb 2024 08:39:40 -0800 (PST) Received: from ?IPV6:2001:16b8:2a4b:b700:a2c8:b49e:756c:9d34? (200116b82a4bb700a2c8b49e756c9d34.dip.versatel-1u1.de. [2001:16b8:2a4b:b700:a2c8:b49e:756c:9d34]) by smtp.gmail.com with ESMTPSA id bt27-20020a056000081b00b0033d1b653e4csm14529621wrb.54.2024.02.20.08.39.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Feb 2024 08:39:40 -0800 (PST) Message-ID: Date: Tue, 20 Feb 2024 17:39:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: gcc-patches , Thomas Schwinge , Jakub Jelinek From: Tobias Burnus Subject: [Patch] OpenMP/nvptx: support 'arch(nvptx64)' as context selector X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org I just encountered 'arch(nvptx64)'. I think it makes sense to support it as alias for 'nvptx' in the context selector for better compatibility. Comments, remarks, suggestions? Tobias PS: See the LLVM documentation below. I do note that those are not identical as LLVM uses 'nvptx' for 32bit while we effectively only support 64bit (at least for offloading). Thus, while 'nvptx' might cause problems, adding 'nvptx64' in addition should be harmless. * * * From LLVM's https://android.googlesource.com/toolchain/llvm/+/refs/heads/master/docs/NVPTXUsage.rst "The NVPTX target uses the module triple to select between 32/64-bit code generation and the driver-compiler interface to use. The triple architecture can be one of ``nvptx`` (32-bit PTX) or ``nvptx64`` (64-bit PTX). The operating system should be one of ``cuda`` or ``nvcl``, which determines the interface used by the generated code to communicate with the driver. Most users will want to use ``cuda`` as the operating system, which makes the generated PTX compatible with the CUDA Driver API. Example: 32-bit PTX for CUDA Driver API: ``nvptx-nvidia-cuda`` Example: 64-bit PTX for CUDA Driver API: ``nvptx64-nvidia-cuda``" And usage inside LLVM: clang/lib/Headers/openmp_wrappers/complex: device = {arch(amdgcn, nvptx, nvptx64)}, \ OpenMP/nvptx: support 'arch(nvptx64)' as context selector The main 'arch' context selector for nvptx is, well, 'nvptx'; however, as 'nvptx64' is used as by LLVM, it makes sense to support it as well. Note that LLVM has: "The triple architecture can be one of ``nvptx`` (32-bit PTX) or ``nvptx64`` (64-bit PTX)." GCC effectively only supports the 64bit variant (at least for offloading). Thus, GCC's 'nvptx' is not quite the same as LLVM's. gcc/ChangeLog: * config/nvptx/gen-omp-device-properties.sh: Add 'nvptx64' to arch. * config/nvptx/nvptx.cc (nvptx_omp_device_kind_arch_isa): Likewise. libgomp/ChangeLog: * libgomp.texi (OpenMP Context Selectors): Add 'nvptx64' as additional 'arch' value for nvptx. gcc/config/nvptx/gen-omp-device-properties.sh | 2 +- gcc/config/nvptx/nvptx.cc | 2 +- libgomp/libgomp.texi | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/config/nvptx/gen-omp-device-properties.sh b/gcc/config/nvptx/gen-omp-device-properties.sh index 95c754a164f..3666f9746d1 100644 --- a/gcc/config/nvptx/gen-omp-device-properties.sh +++ b/gcc/config/nvptx/gen-omp-device-properties.sh @@ -23,7 +23,7 @@ nvptx_sm_def="$1/nvptx-sm.def" sms=$(grep ^NVPTX_SM $nvptx_sm_def | sed 's/.*(//;s/,.*//') echo kind: gpu -echo arch: nvptx +echo arch: nvptx nvptx64 isa="" for sm in $sms; do diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc index 9363d3ecc6a..3b46b70fc3b 100644 --- a/gcc/config/nvptx/nvptx.cc +++ b/gcc/config/nvptx/nvptx.cc @@ -6403,7 +6403,7 @@ nvptx_omp_device_kind_arch_isa (enum omp_device_kind_arch_isa trait, case omp_device_kind: return strcmp (name, "gpu") == 0; case omp_device_arch: - return strcmp (name, "nvptx") == 0; + return strcmp (name, "nvptx") == 0 || strcmp (name, "nvptx64") == 0; case omp_device_isa: #define NVPTX_SM(XX, SEP) \ { \ diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi index d7da799a922..9de6e15f1c2 100644 --- a/libgomp/libgomp.texi +++ b/libgomp/libgomp.texi @@ -6193,7 +6193,7 @@ on more architectures, GCC currently does not match any @code{arch} or @item @code{amdgcn}, @code{gcn} @tab See @code{-march=} in ``AMD GCN Options''@footnote{Additionally, @code{gfx803} is supported as an alias for @code{fiji}.} -@item @code{nvptx} +@item @code{nvptx}, @code{nvptx64} @tab See @code{-march=} in ``Nvidia PTX Options'' @end multitable