From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id D9717394FC2C for ; Tue, 4 May 2021 06:30:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D9717394FC2C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id DF70DAF32; Tue, 4 May 2021 06:30:29 +0000 (UTC) Subject: Re: [committed][nvptx] Set -misa=sm_35 by default To: Thomas Schwinge Cc: gcc-patches@gcc.gnu.org References: <20201009115608.GA26608@delia> <878s8xqc8d.fsf@euler.schwinge.homeip.net> <87k0pyz46d.fsf@euler.schwinge.homeip.net> From: Tom de Vries Message-ID: <59a9d9bb-3a22-26b7-12fc-44c4dda7e0b3@suse.de> Date: Tue, 4 May 2021 08:30:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <87k0pyz46d.fsf@euler.schwinge.homeip.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Tue, 04 May 2021 06:30:32 -0000 On 3/23/21 9:04 AM, Thomas Schwinge wrote: > What is your opinion about backporting that (plus Tobias' documentation > update, plus corresponding web 'changes.html' updates?) to release > branches, so that nvptx offloading users may use GCC 10/9/8 with CUDA > 11.0+? Hmm, so you're talking about making -misa=sm_35 the default for gcc 10/9/8? Let's see, users of the latest nvidia consumer microarchitecture: ampere are forced to use a cuda11.0+ toolchain, which means that the sm_30 default is wrong for them. Cuda 5.x supports both sm_30 and sm_35, so users should be fine. Cuda 4.x supports neither sm_30 nor sm_35, so users also shouldn't observe a difference. There might be users of cuda 4.x or older and a specific newer driver that supports sm_30 but not sm_35, and those will be the only ones affected. I think we can explicitly unsupport that scenario. So, in conclusion, LGTM. Thanks, - Tom