From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 448BA3858437 for ; Wed, 5 Jan 2022 12:45:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 448BA3858437 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-out2.suse.de (Postfix) with ESMTPS id 350D41F37B; Wed, 5 Jan 2022 12:45:08 +0000 (UTC) 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 141FA13BD4; Wed, 5 Jan 2022 12:45:08 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Y6enA9SS1WEYHwAAMHmgww (envelope-from ); Wed, 05 Jan 2022 12:45:08 +0000 Message-ID: <0f545467-f244-f1aa-a71f-66b1fcca5989@suse.de> Date: Wed, 5 Jan 2022 13:45:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH] nvptx: bump default to PTX 4.1 Content-Language: en-US To: Andrew Stubbs , "gcc-patches@gcc.gnu.org" Cc: Tobias Burnus , Jakub Jelinek References: <25ad524d-f0d6-1970-b8e9-9b11b6cde68b@codesourcery.com> <8b5136c0-2d30-8838-e870-78609f3885e6@codesourcery.com> <9583a974-a5a2-ac23-eba1-9cb86ae2f6e4@suse.de> <69fe114c-22eb-9cec-41f6-d03695b6fab1@codesourcery.com> From: Tom de Vries In-Reply-To: <69fe114c-22eb-9cec-41f6-d03695b6fab1@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_NUMSUBJECT, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP 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-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2022 12:45:10 -0000 On 1/5/22 11:33, Andrew Stubbs wrote: > On 05/01/2022 10:24, Tom de Vries wrote: >> On 12/21/21 12:33, Andrew Stubbs wrote: >>> On 20/12/2021 15:58, Andrew Stubbs wrote: >>>> In order to support the %dynamic_smem_size PTX feature is is >>>> necessary to bump the minimum supported PTX version from 3.1 (~2013) >>>> to 4.1 (~2014). >>> >>> Tobias has pointed out, privately, that the default version is both >>> documented and encoded in the -mptx option, so I need to fix that too. >>> >>> This patch adds -mptx=4.1, sets it as the default, and updates the >>> documentation accordingly. >>> >>> The -mptx=3.1 option is kept for backwards compatibility as an alias >>> for 4.1. There's no point in actually allowing 3.1 as any program >>> linked against libgomp will fail (and that's all offloading programs). >>> >>> OK for stage 1? >> >> Just keep -mptx=3.1 as is, and add -mptx=4.1. >> >> AFAIU, there's actually only one file required to have -mptx=4.1, the >> one using %dynamic_smem_size.  Since it's somewhat cumbersome to add >> flags for a single file, how about: >> ... >> diff --git a/libgomp/configure.tgt b/libgomp/configure.tgt >> index d4f1e741b5a..92242697f24 100644 >> --- a/libgomp/configure.tgt >> +++ b/libgomp/configure.tgt >> @@ -162,6 +162,7 @@ case "${target}" in >> >>     nvptx*-*-*) >>          config_path="nvptx accel" >> +       XCFLAGS="$XCFLAGS -mptx=4.1" >>          ;; >> >>     *-*-rtems*) >> ... >> ? > > There shouldn't be any need for that as long as the default is correct. There is no need to change the default, as long as we use this. > In any case, I'm no expert but doesn't the deferred assembly thing mean > that the whole project needs to have the correct minimum setting? > If your question is whether ptx modules with .version 3.1 and 4.1 can be linked together, then the answer seems to be yes. > If the NVPTX maintainer prefers I can leave the 3.1 meaning actually > 3.1, but that will break any makefiles or build scripts that exist in > the wild and happen to specify 3.1 explicitly (not that I know any > reason why they would). I think you're trying to support a scenario we shouldn't support, by making things unclear. Thanks, - Tom