From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by sourceware.org (Postfix) with ESMTPS id B9C3C3858429 for ; Sun, 24 Dec 2023 09:15:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B9C3C3858429 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gcc.gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B9C3C3858429 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.166.47 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703409345; cv=none; b=pAuw3P1J2dgleZCzScHzeVWslPYErgvbxVK0g9ZJ+4wHwKlQ3mZc91HsNuVi+8h9MAxO6IvAI4d4PX9CffFy6ghEQ5yteKmW+Bu8eZ7Gk4zYqVlnYS6+8USAJKRYbeJEMcVlqbv31xAU8ArVTROO6SOpCfz6FZfTQMKpAFrboSw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703409345; c=relaxed/simple; bh=+fNyKXAoftliRuGJbLCne6Vw1RiUNzVary8C6bGdAUA=; h=MIME-Version:From:Date:Message-ID:Subject:To; b=bYOVE58ZhZAi7phCxiU2TBYnYA9lkn8fL527MYDtdtItldNHT5D195Ob15v858h7sZWoRKJSqloISYt36zchpQjDhNXoBvjyd85fzVLzwg3FvtnO7iXIIRw8b4OBjiJAilvNEWJOXSMVBE07Wk2ahPS0s3nJW49CvPcYVZaK1iM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-io1-f47.google.com with SMTP id ca18e2360f4ac-7b7fdde8b56so223423839f.1 for ; Sun, 24 Dec 2023 01:15:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703409339; x=1704014139; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=p8JkSg9Y7Rbv0qalM+gjtLPCJ27UGolDMFAnyuboqAU=; b=C3EsqW5lxCj7UPie6ythuy9oIrph0plhhouyEIspdCWkuJ7GO1HZtpoiNKd36ADe60 QDcbLgLzCfiSu8WHvHhTYE1wpZKQo1yel3A6xrY4vzp8cnwsm2L6PtJx0OAJPgZwTb6/ ZLI45RYwSrOwbZuyT2GCphEcjSsFmPM0JoF5TyHjy66Uzhod8KrqcaeFacpX2ohq+uPV mAM5GAaHaqHnQu2OuX25XBJhYRG9p6IXFnesen3EUy14VzFq0aJLIW24767bN5xXuNQ+ u45eKLYIV5aEF0yLsOEuOMlP0WT2xi6NuiN+Sbh15SA53gcMpvbV5oLhRcP45RoufkPJ oXMQ== X-Gm-Message-State: AOJu0YzozpUyw2qVxd1xaECcEE4t2cyCCcyKMEjGL9zS6eRvLWdsZbHQ M3s2nf5X8Jzrc1W5p/kq7UM9RKQrGxOdQA== X-Google-Smtp-Source: AGHT+IFP5bY/E3kTpLLXPDgqb5qQFUARGhN2/xhFwA62xYOnpxny8GWbMglrm6K2NS/Ububu08BC6A== X-Received: by 2002:a92:ca4a:0:b0:35f:f707:3ec1 with SMTP id q10-20020a92ca4a000000b0035ff7073ec1mr1783530ilo.32.1703409338734; Sun, 24 Dec 2023 01:15:38 -0800 (PST) Received: from mail-il1-f182.google.com (mail-il1-f182.google.com. [209.85.166.182]) by smtp.gmail.com with ESMTPSA id n6-20020a92d9c6000000b0035af9da22b1sm2208383ilq.43.2023.12.24.01.15.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Dec 2023 01:15:38 -0800 (PST) Received: by mail-il1-f182.google.com with SMTP id e9e14a558f8ab-35fe9a6609eso13487405ab.2 for ; Sun, 24 Dec 2023 01:15:38 -0800 (PST) X-Received: by 2002:a05:6e02:1a02:b0:35f:eb24:bb54 with SMTP id s2-20020a056e021a0200b0035feb24bb54mr4510113ild.99.1703409338129; Sun, 24 Dec 2023 01:15:38 -0800 (PST) MIME-Version: 1.0 References: <000901da3603$10e97cb0$32bc7610$@nextmovesoftware.com> <7518ec8d-ac4a-4d3e-a063-caa0ee520acf@gmail.com> <000f01da3646$57092a40$051b7ec0$@nextmovesoftware.com> In-Reply-To: <000f01da3646$57092a40$051b7ec0$@nextmovesoftware.com> From: YunQiang Su Date: Sun, 24 Dec 2023 17:15:26 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] EXPR: Emit an truncate if 31+ bits polluted for SImode To: Roger Sayle Cc: Jeff Law , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,BODY_8BITS,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: Roger Sayle =E4=BA=8E2023=E5=B9=B412=E6=9C=882= 4=E6=97=A5=E5=91=A8=E6=97=A5 16:51=E5=86=99=E9=81=93=EF=BC=9A > > > > 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 seco= nd. 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. > Yes. It is good for me. T_N_T_M_P is a really confusion naming. > When Richard Sandiford "hookized" truly_noop_truncation in 2017 > https://gcc.gnu.org/legacy-ml/gcc-patches/2017-09/msg00836.html > he mentions the inprec/outprec confusion [deciding not to add a > gcc_assert outprec < inprec here, which might be a good idea]. > > The next question is whether this is just > TRULY_NOOP_SIGN_EXTENSION_MODES_P > or whether there are any targets that usefully ensure some modes > are zero-extended forms of others. TRULY_NOOP_ZERO_EXTENSION... > I guess ARM64 is the one TRULY_NOOP_ZERO_EXTENSION? > My vote is that a DINS instruction that updates the most significant > bit of an SImode value should then expand or define_insn_and_split > with an explicit following sign-extension operation. To avoid this being > eliminated by the RTL optimizers/combine the DINS should return a > DImode result, with the following extension truncating it to canonical Is it this one? https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626137.html > SImode form. This preserves the required backend invariant (and > doesn't require tweaking machine-independent code in combine). > SImode DINS instructions that don't/can't affect the MSB, can be a > single SImode instruction. > Yes. As most of MIPS microarchitecture, INS may have slight better performance than DINS. While, I am worrying that: will some body do something like INS ,,24,8 In this case, if is not sign-extended, the result will be UNPREDICTABLE. For this, now, I prefer to use DINS and append a SLL. I tried to write a C code that can produce this case, but not yet success. > Cheers, > Roger > -- > >