From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by sourceware.org (Postfix) with ESMTPS id 5F7D93858C98 for ; Sun, 24 Dec 2023 08:29:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F7D93858C98 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 5F7D93858C98 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.215.171 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703406584; cv=none; b=XjWxW9L6/VeQommibto9ifjpgsBcst4vCf5yYDt3BqCwEsekptaZlVvBWZzmtvjj5tPnvVFg0ExS1MwJCGbydWE3Xwhk1GVVKHkbSzj3tbqrY+/65zKNwTBzzbDYUsNT2KQ1Jt1AhjmzsyX/E9Q30IaJRiTmYIXXLaObbrdq5HE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703406584; c=relaxed/simple; bh=urGxMxcQ6MfGdlJTzFxvpZrVqWVzG0ExuoiX32pDnsI=; h=MIME-Version:From:Date:Message-ID:Subject:To; b=nwfB6lZln2ay8dyZWILUCI+4/b/R3wtlOCpS8b1cUPDpwwPtcE5F2cG3L0ne60lAaDmj4HJceTSVsj2//ZSJs/mXn7enpDm3J4FGpKciL3ZnNpx74wltNlB5BJAdhLadEcfn0DhSlBjtSU/HfhSxl9paEucfEo3By7ocoXZHFf8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-5cd68a0de49so2287859a12.2 for ; Sun, 24 Dec 2023 00:29:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703406578; x=1704011378; 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=O430YcCS3OsQDpuRFFpAtAL7YFyW/rQEBSFbjtsM0mo=; b=wIJIZrlhoeJPz/d5NSLxO5wYAc/NJfu+gHKcsI9dne/9BG0S00StCEuiRL3mL+fxuY yMuArbTJ+GYLbZFh3sRcvtGI6iBLTEETUG19CMY2EvXQvMOXD7RIEmWka8thuymetFf5 mbRZpJwFFhvjAO7vMHb/J+Wzm7qT0Kqg09RRkgEpuEJxMWEbCrM8gktz+XyxxeMbv/B3 TE4G0/hbZkIlJ71dQmCjb5O/hOHpXeGffJmyZOy49jPV4YzhXylaE31tqvJpd5PLw41W lYc2rcPKPS7Xn7z9e4IIzBMzINPkObVOnG6OcgMHqJ8s56kPPPRMUegqihbkgew7Ilkz gU6A== X-Gm-Message-State: AOJu0YyFF35Vhqy3Fmu0eXhocrVp0KN1Yx5cqiWpQEkZNznBGwcUqkGx JAKf4AeZLTZWCXgheJBy0NvIPSa6BsmULw== X-Google-Smtp-Source: AGHT+IHMgrjJWc03vlM4aMvpiYgk4F34AExPbNLp4bJUbqBawPGra55cMIa5DgsQM0tpQBNscbDYKg== X-Received: by 2002:a05:6a20:948a:b0:195:133e:b473 with SMTP id hs10-20020a056a20948a00b00195133eb473mr4140443pzb.23.1703406578005; Sun, 24 Dec 2023 00:29:38 -0800 (PST) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com. [209.85.216.41]) by smtp.gmail.com with ESMTPSA id m3-20020a62f203000000b006d98dd174c5sm3686470pfh.104.2023.12.24.00.29.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Dec 2023 00:29:37 -0800 (PST) Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-28b6218d102so2412258a91.0 for ; Sun, 24 Dec 2023 00:29:37 -0800 (PST) X-Received: by 2002:a17:902:bd88:b0:1d3:b308:adb8 with SMTP id q8-20020a170902bd8800b001d3b308adb8mr3533450pls.17.1703406577590; Sun, 24 Dec 2023 00:29:37 -0800 (PST) MIME-Version: 1.0 References: <000901da3603$10e97cb0$32bc7610$@nextmovesoftware.com> In-Reply-To: <000901da3603$10e97cb0$32bc7610$@nextmovesoftware.com> From: YunQiang Su Date: Sun, 24 Dec 2023 16:29:25 +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: gcc-patches@gcc.gnu.org, Jeff Law 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,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 08:49=E5=86=99=E9=81=93=EF=BC=9A > > > Hi YunQiang (and Jeff), > > > MIPS claims TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) =3D=3D 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 returni= ng > true for TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode). It's true > that the backend stores SImode values in DImode registers by sign extendi= ng > them, but this doesn't mean that any DImode pseudo register can be trunca= ted > 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. > Yes, you are right. While in most case, software/compiler carefully, when work with SI variables, only instructions these instruction are used: 1. the result of this instruction is proper sign-extended, normally, the instructions from MIPS32. 2. or use LW to load the value: LW also will sign-extend the registers. > 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 ? > It will make some performance regression. Use our new tests as an example The result will be: lbu $2,0($4) SLL # newly added lbu $3,1($4) dins $2,$3,8,8 SLL # newly added lbu $3,2($4) dins $2,$3,16,8 SLL # newly added lbu $3,3($4) dins $2,$3,24,8 sll $2,$2 As my previous patch did, here, in fact if we replace all DINS with INS, it will just work. > I agree with Jeff there's an invariant that isn't correctly being modelle= d > 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. > The addsi3 on MIPS64 is like: (define_insn "*addsi3_extended" [(set (match_operand:DI 0 "register_operand" "=3Dd,d") (sign_extend:DI (plus:SI (match_operand:SI 1 "register_operand" "d,d") (match_operand:SI 2 "arith_operand" "d,Q"))))] "TARGET_64BIT && !TARGET_MIPS16" "@ addu\t%0,%1,%2 addiu\t%0,%1,%2" [(set_attr "alu_type" "add") (set_attr "mode" "SI")]) It expect the source register is in SImode. And in fact in the ISA documents: the result of ADD/ADDU will be UNPREDICTABLE if sources is not well sign-extended. > Just my thoughts. I'm curious what other folks think. > > Cheers, > Roger > -- > >