From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 16AEB383163F for ; Sun, 18 Sep 2022 08:53:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 16AEB383163F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id F16C22227A; Sun, 18 Sep 2022 08:53:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1663491231; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3LUwaF8RKBdruyz8BP89WizN1aoZKzFoqoSc2tFYOlE=; b=nwf4FOiBoWsClgGWXnD9BTlBZh+5Nx/KsN1H8d0cmRuGIwzkvXveSwWPahch/yJ0d2prK6 RQmcAj/KFvk2TcJ1iqikJssJLamNbevZOPqGqjuNLp6mz38ERK65BpVeYoLVrxaBGbBnrO c+mhBBwBjK6v752y1hakjT7ptfVJEhc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1663491231; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3LUwaF8RKBdruyz8BP89WizN1aoZKzFoqoSc2tFYOlE=; b=KKhVc1JaK5IIHnVqpyvt5mNWo3/LTLmH5EV13xiEjrSN9y5pNt1+M+mU+MdVwGSdt1jm/s hkJHJPJqmaQcvuDQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B663413A6B; Sun, 18 Sep 2022 08:53:51 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id JdH2KZ/cJmMsOwAAMHmgww (envelope-from ); Sun, 18 Sep 2022 08:53:51 +0000 Message-ID: <912ccc9f-3a4c-02df-191c-34b1a1d6ed2e@suse.de> Date: Sun, 18 Sep 2022 10:53:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PING^5] nvptx: Allow '--with-arch' to override the default '-misa' (was: nvptx multilib setup) Content-Language: en-US To: Thomas Schwinge , gcc-patches@gcc.gnu.org References: <87r18jt7uu.fsf@euler.schwinge.homeip.net> <87o801see9.fsf@euler.schwinge.homeip.net> <874k0lmxrh.fsf@dem-tschwing-1.ger.mentorg.com> <871quz61x0.fsf@euler.schwinge.homeip.net> <875yk14d4r.fsf@euler.schwinge.homeip.net> <87v8rsrlys.fsf@dem-tschwing-1.ger.mentorg.com> <874jz236ad.fsf@dem-tschwing-1.ger.mentorg.com> <87iln518mx.fsf@dem-tschwing-1.ger.mentorg.com> From: Tom de Vries In-Reply-To: <87iln518mx.fsf@dem-tschwing-1.ger.mentorg.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 8/6/22 21:20, Thomas Schwinge wrote: > Hi Tom! > Hi Thomas, thanks for doing this. Series approved. As I mentioned, I'm not completely happy with the multilib name, but I don't think it makes sense to post-pone approval for this. Thanks, - Tom > Ping. > > > Grüße > Thomas > > > On 2022-07-27T17:48:58+0200, I wrote: >> Hi Tom! >> >> Ping. >> >> >> Grüße >> Thomas >> >> >> On 2022-07-20T14:46:03+0200, I wrote: >>> Hi Tom! >>> >>> Ping. >>> >>> >>> Grüße >>> Thomas >>> >>> >>> On 2022-07-13T10:42:44+0200, I wrote: >>>> Hi Tom! >>>> >>>> Ping. >>>> >>>> >>>> Grüße >>>> Thomas >>>> >>>> >>>> On 2022-07-05T16:59:23+0200, I wrote: >>>>> Hi Tom! >>>>> >>>>> Ping. >>>>> >>>>> >>>>> Grüße >>>>> Thomas >>>>> >>>>> >>>>> On 2022-06-15T23:18:10+0200, I wrote: >>>>>> Hi Tom! >>>>>> >>>>>> On 2022-05-13T16:20:14+0200, I wrote: >>>>>>> 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=3.1 , -mptx=6.3 } x { GOMP_NVPTX_JIT=-O0, }. >>>>>>>>> >>>>>>>>> Do you use separate (nvptx-none offload target only?) builds for >>>>>>>>> different '-mptx' variants (likewise: '-misa'), or have you hacked up the >>>>>>>>> multilib configuration? >>>>>>>> >>>>>>>> Neither, I'm using --target_board=unix/foffload= 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=3.1'. >>>>>>> >>>>>>> Meaning, one can't just use such a flag for "completely building code" >>>>>>> for a specific configuration. Random example, >>>>>>> '-foffload-options=nvptx-none=-march=sm_75': as GCC/nvptx target >>>>>>> libraries aren't being built for '-march=sm_75' multilib, >>>>>>> '-foffload-options=nvptx-none=-march=sm_75' uses the default multilib, >>>>>>> which isn't '-march=sm_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=[...]', as supported for a >>>>>>>>> few other targets?)? (I see there's also a new >>>>>>>>> '--with-multilib-generator=[...]', haven't looked in detail.) No matter >>>>>>>>> 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=[...]', or >>>>>>> '--with-multilib-generator=[...]', 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? >>>>>> >>>>>> So, instead of "random GCC/nvptx multilib configuration" (last >>>>>> paragraph), I've come up with a way to implement our customer's request >>>>>> (second last paragraph): 'configure' GCC/nvptx '--with-arch=sm_70'. >>>>>> >>>>>> I think I've implemented this in a way so that "random GCC/nvptx multilib >>>>>> configuration" may eventually be implemented on top of that. For easy >>>>>> review/testing I've split my changes into three commits, see attached >>>>>> "nvptx: Make default '-misa=sm_30' explicit", >>>>>> "nvptx: Introduce dummy multilib option for default '-misa=sm_30'", >>>>>> "nvptx: Allow '--with-arch' to override the default '-misa'". >>>>>> >>>>>> To the best of my knowledge, the first two patches do not change any >>>>>> user-visible behavior (I generally 'diff'ed target libraries, and >>>>>> compared a good number of 'gcc -print-multi-directory [flags]'), and >>>>>> likewise with the third patch, given implicit (default) or explicit >>>>>> '--with-arch=sm_30', and that with '--with-arch=sm_70', for example, the >>>>>> '-misa=sm_70' multilib variants are used for implicit (default) or >>>>>> explicit '-misa=sm_70' or higher, and the '-misa=sm_30' multilib variants >>>>>> are used for explicit lower '-misa'. >>>>>> >>>>>> What do you think, OK to push to master branch? >>>>>> >>>>>> >>>>>> Grüße >>>>>> Thomas > > > ----------------- > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955