From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server.nextmovesoftware.com (server.nextmovesoftware.com [162.254.253.69]) by sourceware.org (Postfix) with ESMTPS id E0A973857817 for ; Tue, 22 Feb 2022 16:08:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E0A973857817 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nextmovesoftware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nextmovesoftware.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nextmovesoftware.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SZ82+gPfONgS6LJLcwZ2m5/tefXSMdH8VfHLaolmpIA=; b=p16N4vWAsWylzVOegWiKJZGRNq Nt6Ml2q/4j6ZQ68g7VbKF3LK9CXKV1H1KWqUphOvvaFuAVvGPRMFzqq4MMnxpAhmqIUXuIBJXz0ec ALJGTRqTWwwGtHtD7cVmDS61FfG8+pCt1/2WLWFRV+2uFGRs94FtTytThS/vCmmUdChTC75oPob69 Ka69/om2EQ580NAOJCKSozrN7sXfNOZqqGhUke6lKwwkH9yvhOd4HrIi+Kpin+OdjQQt2xGR9+RXg QT5x21Rd735DuxOLOUXkNV4FzmNRKC+NA0AzQid5uOcRHAddQLXuQsd+106NN66Cm8k0WwmP6gTEA tHpFV8kQ==; Received: from host86-186-213-42.range86-186.btcentralplus.com ([86.186.213.42]:50289 helo=Dell) by server.nextmovesoftware.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nMXiX-0007N4-9U; Tue, 22 Feb 2022 11:08:45 -0500 From: "Roger Sayle" To: "'Tom de Vries'" , References: <057201d81df1$50523bc0$f0f6b340$@nextmovesoftware.com> <9f961501-f2a6-031e-11ee-2afc762f2f5d@suse.de> In-Reply-To: <9f961501-f2a6-031e-11ee-2afc762f2f5d@suse.de> Subject: RE: [PATCH] middle-end: Support ABIs that pass FP values as wider integers. Date: Tue, 22 Feb 2022 16:08:41 -0000 Message-ID: <008801d82806$771db4e0$65591ea0$@nextmovesoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJ9RK1A/mLmQI2lFVOi8QF0uUeM9QHLAqBAq0clWTA= Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.nextmovesoftware.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nextmovesoftware.com X-Get-Message-Sender-Via: server.nextmovesoftware.com: authenticated_id: roger@nextmovesoftware.com X-Authenticated-Sender: server.nextmovesoftware.com: roger@nextmovesoftware.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: Tue, 22 Feb 2022 16:08:48 -0000 Hi Tom, I'll admit that I'd not myself considered the ABI issues when I = initially proposed experimental HFmode support for the nvptx backend, and was surprised = when I finally tracked down the source of the problem you'd reported: that = libgcc spots HFmode support exists and immediately starts passing/returning = values in this type. The one precedent that I can point to is that LLVM's nvptx backend = passes HFmode values in SImode regs, see https://reviews.llvm.org/D28540 Their motivation is that not all PTX ISAs support fp16, so for = compatibility with say sm_30/sm_35, fp16 values are treated like b16, i.e. HImode. At this point, the nvptx ABI states that HImode values are passed as = SImode, so we end up with the interesting mismatch of HFmode<->SImode. I guess the same thing affects host code, where an i386/x86 host that doesn't support 16-bit floating point, can pass "unsigned short" values to and from the accelerator, and likewise this HImode locally gets = passed in a wider (often WORD_MODE) integer types on most x86 ABIs. My guess is that passing SFmode in DImode may have been supported in older versions of GCC, before handling of SUBREGs was tightened up, so this might be considered a regression. Cheers, Roger -- > -----Original Message----- > From: Tom de Vries > Sent: 22 February 2022 15:43 > To: Roger Sayle ; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH] middle-end: Support ABIs that pass FP values as = wider > integers. >=20 > On 2/9/22 21:12, Roger Sayle wrote: > > > > This patch adds middle-end support for target ABIs that pass/return > > floating point values in integer registers with precision wider than > > the original FP mode. An example, is the nvptx backend where 16-bit > > HFmode registers are passed/returned as (promoted to) SImode = registers. > > Unfortunately, this currently falls foul of the various (recent?) > > sanity checks that (very sensibly) prevent creating paradoxical > > SUBREGs of floating point registers. The approach below is to > > explicitly perform the conversion/promotion in two steps, via an > > integer mode of same precision as the floating point value. So on > > nvptx, 16-bit HFmode is initially converted to 16-bit HImode (using > > SUBREG), then zero-extended to SImode, and likewise when going the > > other way, parameters truncated to HImode then converted to HFmode > > (using SUBREG). These changes are localized to expand_value_return > > and expanding DECL_RTL to support strange ABIs, rather than inside > > convert_modes or gen_lowpart, as mismatched precision integer/FP > > conversions should be explicit in the RTL, and these semantics not = generally > visible/implicit in user code. > > >=20 > Hi Roger, >=20 > I cannot comment on the patch, but I do wonder (after your "strange = ABI" > comment): did we actively decide on (or align to) a register passing = ABI for > HFmode, or has it merely been decided by the implementation of > promote_arg: > ... > static machine_mode > promote_arg (machine_mode mode, bool prototyped) { > if (!prototyped && mode =3D=3D SFmode) > /* K&R float promotion for unprototyped functions. */ > mode =3D DFmode; > else if (GET_MODE_SIZE (mode) < GET_MODE_SIZE (SImode)) > mode =3D SImode; >=20 > return mode; > } > ... >=20 > There may be a rationale why it's good to pass a HF as SI, but it's = not > documented there. >=20 > Anyway, I checked what cuda does for HF, and it passes a byte array: > ... > .param .align 2 .b8 _Z5helloPj6__halfs_param_1[2], ... >=20 > So, I guess what I'm saying is I'd like to understand why we're having = the HF -> SI > promotion. >=20 > Thanks, > - Tom