From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by sourceware.org (Postfix) with ESMTPS id 4E6723858CDA for ; Mon, 27 Mar 2023 01:36:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4E6723858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yb1-xb34.google.com with SMTP id r187so8573866ybr.6 for ; Sun, 26 Mar 2023 18:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679881015; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fMeyiuafpdvazbWUrzPQq3TNTxGP6ql4Gw4obuc68wc=; b=E2ZKIeEQGHWqnzzD+wX3S4f65+cGbgPqLbSbIPuxb1dfXxsTDi7v1Se8QIHsv+wzfC 7nmDwjSLh0arJa2jc88gO501Txetuuc3NVPPiOSJXt7nfJFYjMGnUY3sg2vEFQurdVMT cS1tKP0SawNjKqlJh5uKvOnawolkTMCQBvqa14sO03l1TIOlewBuWYgQTehcpUUtVdJ1 kfNZlIt9ozGND7JZIsXOR8NOtdIdDNPsSCmWeH3CBTtjwKNi5Uf49HmR3/kzb6rtPYfz vF50F7L5IrZtzv8Z1N+EJAhm+9QoDNDuDDlPFi6F/XPVm3iF1Etm4tAGd9fYCWc/4Qss FZQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679881015; 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=fMeyiuafpdvazbWUrzPQq3TNTxGP6ql4Gw4obuc68wc=; b=bF0I91wrW3hoonUmA3TjaQyzVgodux+/NgmcJivNnrkQU3r59ji1MhJVHdrykLwKpr y5Ers8So5SOqq3wopAAZyK1yT9L66esFDFRLtsAsUWW9YYo12zfasBZMKOCHgb91rPJ0 R6vxh7/jmfyCGKtwnuqN49/sVpXuvCL0Wq4jlalrqGqtWvUsBdi3uXLg6LVV1WJbp/lF XyipJPpx4+IWhfNwuzuyhZGeJt1ZGf/a6ah1VxO46bkLiQypCAE3eyvTiIBzjNvlOi9I ub/LmlTzoSX4qpq99p60vwoNALMrNO9pxqTvDwWM2bf2fuVw+uBrRYl7OTm6OEc6ZQ12 kbuQ== X-Gm-Message-State: AAQBX9fRruR6VAv1kGD/RPj3yQjFDnS3/nbtNG4KAUjcmlyL9sXN7afu 7R9a08CN+5gRfY9FbUQn1MIISvM50qKQ0G6/HAg= X-Google-Smtp-Source: AKy350ZvYEKwNAXEIViIRA+rSmhMGast/2xVJ9LCSuLzl9ewCo3SWwoqki+ziUdhprrkYzGoc5kV597MlawynHOxbjM= X-Received: by 2002:a25:ab11:0:b0:a5f:0:bf12 with SMTP id u17-20020a25ab11000000b00a5f0000bf12mr4161156ybi.13.1679881015264; Sun, 26 Mar 2023 18:36:55 -0700 (PDT) MIME-Version: 1.0 References: <20230324141157.1646192-1-pan2.li@intel.com> <9aa74d50-a9db-7747-524e-9da839366433@gmail.com> In-Reply-To: <9aa74d50-a9db-7747-524e-9da839366433@gmail.com> From: Hongtao Liu Date: Mon, 27 Mar 2023 09:36:44 +0800 Message-ID: Subject: Re: [PATCH] RTL: Bugfix for wrong code with v16hi compare & mask To: Jeff Law Cc: 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,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sun, Mar 26, 2023 at 3:01=E2=80=AFAM Jeff Law via Gcc-patches wrote: > > > > On 3/24/23 08:11, pan2.li--- via Gcc-patches wrote: > > From: Pan Li > > > > Fix the bug of the incorrect code generation for the > > below code sample. > > > > typedef unsigned short __attribute__((__vector_size__ (32))) V; > > typedef unsigned short u16; > > > > void > > foo (V m, u16 *ret) > > { > > V v =3D 6 > ((V) { 2049, 8 } & m); > > *ret =3D v[0]; // + a + b + c + d; > > } > > > > Before this patch. > > addi sp,sp,-64 > > ld a5,0(a0) > > li a4,528384 > > addi a4,a4,-2047 > > and a5,a5,a4 > > // slli a5,a5,48 <- eliminated by mistake > > // srli a5,a5,48 <- eliminated by mistake > > sltiu a5,a5,6 > > negw a5,a5 > > sh a5,0(a1) > > > > After this patch. > > addi sp,sp,-64 > > ld a5,0(a0) > > li a4,528384 > > addi a4,a4,-2047 > > and a5,a5,a4 > > slli a5,a5,48 > > srli a5,a5,48 > > sltiu a5,a5,6 > > negw a5,a5 > > sh a5,0(a1) > > > > The simplify_comparation for the AND operation will > > try to simplify below RTL code from: > > (and:DI (subreg:DI (reg:HI 154) 0) (const_int 0x801)) > > to: > > (subreg:DI (and (reg:HI 154) (const_int 0x801)) 0) > These look equivalent to me -- assuming they're used as rvalues. They're equivalent only when WORD_REGISTER_OPERATIONS, orelse the upper bits of latter is UD, but the former is 0. (and (reg:HI 154) (const_int 0x801)) is simplified to (reg:HI 154) since nonzero_bits (reg:154, HImode) is exactly same as 0x801. These two optimizations are fine on their own, but if they are put together, there are problems. The first optimization relies on the WORD_REGISTER_OPERATIONS, but the second optimize the operation off which make upper bits of (subreg:DI (reg:HI 154) 0) UD, but originally it should be 0 after AND (const_int 0x801). > > > > > > If reg:HI 154 is 0x801 and reg:DI 154 is 0x80801, the RTL will > > be simplified continuely to: > That statement has no meaning. Each pseudo has one and only one native > mode and you can only refer to it in that mode. ie reg:HI 154. reg:DI > 154 has no meaning. You might say that (subreg:DI (reg:HI 154) 0) has > the value 0x80801, but that's OK. The subreg says those bits outside > HImode simply don't matter -- you can not depend on them having any > particular value. > > > (subreg:DI (reg:HI 154) 0) > I think that's equivalent to (subreg:DI (and:HI (reg:HI 154) (const_int > 0x801)) 0) when used as an rvalue. > > I suspect your problem is elsewhere. > > jeff > --=20 BR, Hongtao