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 5F11B395C04A for ; Fri, 13 May 2022 14:20:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5F11B395C04A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.91,223,1647331200"; d="scan'208";a="75872609" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 13 May 2022 06:20:24 -0800 IronPort-SDR: SHlZfwuBGt5mAAShgMl419knrE2gUNwZlh4vv+wLCRU6MzU8bJ3lMFwWY4Y4PtWSepc4aSTmRj cVG/VNMLqhg74dVndXhoYCuVKB0ljAJ63IolGGe+TMmDnVQBYiXuYVbegOfkTuwcfckJbpfpWH iiXxi95Wdyz8a70xmMWhcP4ebwemfLADQXfw7hKIoijYVlj5efkoeK6aEoVkkK79OPTmUyTG1O X19wUbfLT+ECxHm3xkASq1tkL7oFHrks6/5m6hqxLySapXacaWXxo5q4S2ewmud1//wN/OuCcm K1E= From: Thomas Schwinge To: Tom de Vries CC: Subject: Re: nvptx multilib setup In-Reply-To: References: <87r18jt7uu.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Fri, 13 May 2022 16:20:14 +0200 Message-ID: <87o801see9.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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@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: Fri, 13 May 2022 14:20:32 -0000 Hi Tom! On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc wrote: > On 2/4/22 08:21, Thomas Schwinge wrote: >> On 2022-02-03T13:35:55+0000, "vries at gcc dot gnu.org via Gcc-bugs" wrote: >>> I've tested this using (recommended) driver 470.94 on boards: >>> while iterating over dimensions { -mptx=3D3.1 , -mptx=3D6.3 } x { GOMP_= NVPTX_JIT=3D-O0, }. >> >> Do you use separate (nvptx-none offload target only?) builds for >> different '-mptx' variants (likewise: '-misa'), or have you hacked up th= e >> multilib configuration? > > Neither, I'm using --target_board=3Dunix/foffload=3D for that. ACK, I see. So these flags then only affect GCC/nvptx code generation for the actual user code (here: GCC libgomp test cases), but for the GCC/nvptx target libraries (such as: libc, libm, libgfortran, libgomp -- the latter especially relevant for OpenMP), it uses PTX code from one of the two "pre-compiled" GCC/nvptx multilibs: default or '-mptx=3D3.1'. Meaning, one can't just use such a flag for "completely building code" for a specific configuration. Random example, '-foffload-options=3Dnvptx-none=3D-march=3Dsm_75': as GCC/nvptx target libraries aren't being built for '-march=3Dsm_75' multilib, '-foffload-options=3Dnvptx-none=3D-march=3Dsm_75' uses the default multilib= , which isn't '-march=3Dsm_75'. > ('gcc/config/nvptx/t-nvptx:MULTILIB_OPTIONS' >> etc., I suppose?) Should we add a few representative configurations to >> be built by default? And/or, should we have a way to 'configure' per >> user needs (I suppose: '--with-multilib-list=3D[...]', as supported for = a >> few other targets?)? (I see there's also a new >> '--with-multilib-generator=3D[...]', haven't looked in detail.) No matt= er >> which way: again, combinatorial explosion is a problem, of course... > > As far as I know, the gcc build doesn't finish when switching default to > higher than sm_35, so there's little point to go to a multilib setup at > this point. But once we fix that, we could reconsider, otherwise, > things are likely to regress again. As far as I remember, several issues have been fixed. Still waiting for Roger's "middle-end: Support ABIs that pass FP values as wider integers" or something similar, but that PR104489 issue is being worked around by "Limit HFmode support to mexperimental", if I got that right. Now I'm not suggesting we should now enable all or any random GCC/nvptx multilibs, to get all these variants of GCC/nvptx target libraries built; especially also given that GCC/nvptx code generation currently doesn't make too much use of the new capabilities. However, we do have a specific request that a customer would like to be able to change at GCC 'configure' time the GCC/nvptx default multilib (including that being used for building corresponding GCC/nvptx target libraries). Per 'gcc/doc/install.texi', I do see that some GCC targets allow for GCC 'configure'-time '--with-multilib-list=3D[...]', or '--with-multilib-generator=3D[...]', and I suppose we could be doing something similar? But before starting implementing, I'd like your input, as you'll be the one to approve in the end. And/or, maybe you've already made up your own ideas about that? Gr=C3=BC=C3=9Fe Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955