From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tdevries@suse.de>
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28])
 by sourceware.org (Postfix) with ESMTPS id 310C53858431
 for <gcc-patches@gcc.gnu.org>; Tue, 22 Feb 2022 15:42:53 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 310C53858431
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 D9E70212BF;
 Tue, 22 Feb 2022 15:42:51 +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 C261713BC3;
 Tue, 22 Feb 2022 15:42:51 +0000 (UTC)
Received: from dovecot-director2.suse.de ([192.168.254.65])
 by imap2.suse-dmz.suse.de with ESMTPSA id PpTNLXsEFWIZKwAAMHmgww
 (envelope-from <tdevries@suse.de>); Tue, 22 Feb 2022 15:42:51 +0000
Message-ID: <9f961501-f2a6-031e-11ee-2afc762f2f5d@suse.de>
Date: Tue, 22 Feb 2022 16:42:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.4.1
Subject: Re: [PATCH] middle-end: Support ABIs that pass FP values as wider
 integers.
Content-Language: en-US
To: Roger Sayle <roger@nextmovesoftware.com>, gcc-patches@gcc.gnu.org
References: <057201d81df1$50523bc0$f0f6b340$@nextmovesoftware.com>
From: Tom de Vries <tdevries@suse.de>
In-Reply-To: <057201d81df1$50523bc0$f0f6b340$@nextmovesoftware.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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 <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Feb 2022 15:42:54 -0000

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.
> 

Hi Roger,

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 == SFmode)
     /* K&R float promotion for unprototyped functions.  */
     mode = DFmode;
   else if (GET_MODE_SIZE (mode) < GET_MODE_SIZE (SImode))
     mode = SImode;

   return mode;
}
...

There may be a rationale why it's good to pass a HF as SI, but it's not 
documented there.

Anyway, I checked what cuda does for HF, and it passes a byte array:
...
.param .align 2 .b8 _Z5helloPj6__halfs_param_1[2],
...

So, I guess what I'm saying is I'd like to understand why we're having 
the HF -> SI promotion.

Thanks,
- Tom