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 AD1DE3858D3C; Sun, 24 Dec 2023 12:25:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AD1DE3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nextmovesoftware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nextmovesoftware.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AD1DE3858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=162.254.253.69 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703420703; cv=none; b=O++1OWjjak9cnzKwnDq6/jODF+ENVveCvJ6LKPsUCAqHgsg5TMQsRTKgbegYH/1kQb3VWU8sJuj2CJJZ6NR7D31sDbvohlTfSmC1CBF5Sbl+o5T/qwXhoT3UzduzgPZUXpsENPbIQk0MxUuKr98YJs02MKqG19QWaGWxfgbN33c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703420703; c=relaxed/simple; bh=XTqHRbAxbPoEF6fNTGtc4NZ5Qat9xst9yNe4UKdGCP8=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=MZ/a8HlSFwLRp3e1l0oVX/drOI74WBUfn7HkdOSItwtYQxIsW3vwUf1lNkwUywWg8wfGi5qQZ5LpCAg+rqUUJyyuOXRiJYwr7rpMp/blaS4uYk7ipGCml00gSb88dSBN6LL1zPQ4cgViZ+9ID6AMJyIEE+GcxXOxublLr640xjc= ARC-Authentication-Results: i=1; server2.sourceware.org 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:Cc:To:From:Sender :Reply-To: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=ZGAlUZP3e/YwaIVGaCYN5OsMbgqz68cVKr6kydgO4p8=; b=V+BQZUpGkT6K12Ll9koFUADKCk 7to63j13hx67Dbqzt7WTSuN2JRYTSDkLXOUraGdweuvG1G/jdJFOipBx9xcM0cN07Cu1DUMzFb9O0 TzD8I/oPZwrV4309OWKuhd7OVxipcF31wnhCRH7bOvq07gkepW1TaKEAhm3El0lnjChcHqhC3kj6+ 9dIJgDbpiaX5x8+bdcqaecFROy1HT2qigUY9lsfOKoXAPKizYLm9QfAZF07uvHLSQ/ikUr4LTrw4i fojcdd89uPw42MR+DdJyo/d8Nk2Ol8ZcZefwuGGOPokozW6BBt6MtMrArw+CECbCAnx9i/5SiH36h eSxM8KXg==; Received: from host86-131-181-50.range86-131.btcentralplus.com ([86.131.181.50]:55248 helo=Dell) by server.nextmovesoftware.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1rHNXQ-0005so-1y; Sun, 24 Dec 2023 07:25:01 -0500 From: "Roger Sayle" To: "'YunQiang Su'" Cc: "'Jeff Law'" , References: <000901da3603$10e97cb0$32bc7610$@nextmovesoftware.com> <7518ec8d-ac4a-4d3e-a063-caa0ee520acf@gmail.com> <000f01da3646$57092a40$051b7ec0$@nextmovesoftware.com> In-Reply-To: Subject: RE: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode Date: Sun, 24 Dec 2023 12:24:57 -0000 Message-ID: <002201da3664$364d0e20$a2e72a60$@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: AQIPig1yJLhWGJeSoAfmXCDq4sKpYAJLUD0RAdDFKD0DOtFvlrAS+VHg 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=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > > > What's exceedingly weird is T_N_T_M_P (DImode, SImode) isn't > > > actually a truncation! The output precision is first, the input > > > precision is second. The docs explicitly state the output = precision > > > should be smaller than the input precision (which makes sense for = truncation). > > > > > > That's where I'd start with trying to untangle this mess. > > > > Thanks (both) for correcting my misunderstanding. > > At the very least might I suggest that we introduce a new > > TRULY_NOOP_EXTENSION_MODES_P target hook that MIPS can use for this > > purpose? It'd help reduce confusion, and keep the > > documentation/function naming correct. > > >=20 > Yes. It is good for me. > T_N_T_M_P is a really confusion naming. Ignore my suggestion for a new target hook. GCC already has one. You shouldn't be using TRULY_NOOP_TRUNCATION_MODES_P with incorrectly ordered arguments. The correct target hook is=20 TARGET_MODE_REP_EXTENDED, which the MIPS backend correctly defines via mips_mode_rep_extended. It's MIPS definition of (and interpretation of) = mips_truly_noop_truncation that's suspect. My latest theory is that these sign extensions should be: (set (reg:DI) (sign_extend:DI (truncate:SI (reg:DI)))) and not (set (reg:DI) (sign_extend:DI (subreg:SI (reg:DI)))) If the RTL optimizer's ever split this instruction the semantics of the SUBREG intermediate are incorrect. Another (less desirable) approach might be to use an UNSPEC.