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 76D8C3858D3C; Sun, 24 Dec 2023 00:49:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 76D8C3858D3C 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 76D8C3858D3C 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=1703378977; cv=none; b=qJGsVMlQiWKqmaRrO+nnBSoBZDStbP8Ai46WbWooFNFlZr1tB/EDwhhtKEkNmmkMjD4JjkSv2n0YDiXlkt+caXE+YuVqI/QyOyWQ4vDgtx4CW9vVz4FebgJ+hgnEW+YSrsCSw4cZdqepNqGqkO4Ff6+o4ZFy406oxrzZulQLx8Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703378977; c=relaxed/simple; bh=oGqIDvuLM0kTNmar2khaGf9jHdi0EfMHYheq2QMbTZo=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=wn3TibUVLIFhZHIdu4aXvwOS3u/OcCT9eJxmVuugAevRxH2292JwEtwWtad3olPcoSV+pwIFYXGvcOmgDX74ceqYpbl/LfqwJoYcHTEL8bmvqnaO4ub0fOEPCzfGnbUMkhMlLvRSyiFPXJTIu4ZI8E15y0f9ijkVsetfEipLdYU= 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:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=U9YwRYcMOCfOEwDEc2Dn0l1cT4fn25d1DzLg7dUh8PA=; b=bFc3IDnGH5Gr7j4x3wEXzkuXAu F2Ll6srytOZeX0fQQ8CaN417m7SfYzVQvZrCcxPKyH5zOcdk+p1pPi2lpwkpemK9XllNASSGNhc9Y +Y4SEWZ57GzGWPyGNJKujwMNJglv7GXqvfH/dtoPBtjZRgDUrCzSUZjcJ4JvxX7TckogmAREwcDuM LITeHFbOGhROMBJKC5+4TOTILDJdT0P5otkiUcyccDwn61OfkSEMfTnITJ9hKUCIXmezlWmixLKqW ROHxVOKO/HJK9EGiPXqX9JxcSt7tWtf2hxIDUUxIRzIsefBDjuwVJ7XR7RZEEO4HoEHCFKxy0TnWw U4D5fz+w==; Received: from host86-131-181-50.range86-131.btcentralplus.com ([86.131.181.50]:59924 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 1rHCgR-0003MY-34; Sat, 23 Dec 2023 19:49:36 -0500 From: "Roger Sayle" To: , "'YunQiang Su'" Cc: "'Jeff Law'" Subject: Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode Date: Sun, 24 Dec 2023 00:49:33 -0000 Message-ID: <000901da3603$10e97cb0$32bc7610$@nextmovesoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: Ado2AvpW2I2l4YwkRZehcRTz7vNTRA== 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: Hi YunQiang (and Jeff), > MIPS claims TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true > based on that the hard register is always sign-extended, but here > the hard register is polluted by zero_extract. I suspect that the bug here is that the MIPS backend shouldn't be returning true for TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode). It's true that the backend stores SImode values in DImode registers by sign extending them, but this doesn't mean that any DImode pseudo register can be truncated to an SImode pseudo just by SUBREG/register naming. As you point out, if the high bits of a DImode value are random, truncation isn't a no-op, and requires an explicit sign-extension instruction. There's a PR in Bugzilla around this representational issue on MIPS, but I can't find it straight away. Out of curiosity, how badly affected is the testsuite if mips.cc's mips_truly_noop_truncation (poly_uint64 outprec, poly_uint64 inprec) is changed to just return !TARGET_64BIT ? I agree with Jeff there's an invariant that isn't correctly being modelled by the MIPS machine description. A machine description probably shouldn't define an addsi3 pattern if what it actually supports is (sign_extend:DI (truncate:SI (plus:DI (reg:DI x) (reg:DI y)))) Trying to model this as SImode addition plus a SUBREG_PROMOTED flag is less than ideal. Just my thoughts. I'm curious what other folks think. Cheers, Roger --