From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) by sourceware.org (Postfix) with ESMTPS id 3337B385735F for ; Tue, 10 May 2022 06:30:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3337B385735F Received: by mail-vs1-xe31.google.com with SMTP id y74so15982645vsy.7 for ; Mon, 09 May 2022 23:30:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DbEYD/qdaHLDmh5fT5uQimzgdL454bnu8EI0SuL7xwQ=; b=rbGtSabDBbzwu5gntjxdBSnXIbZ0LmccYi4VNRtuvzUC2K9eMALHWXGmh68yG9lf/A +jjmMIGBz4OLlSt0lrAcy/p6Yj5d+nQ54oVXHU6sReK0fd6q2Q0u3FC6Xe3z0+d0ZnQs adqyRqGKcSFUKrthrcQmEogact3WGFJTPSTmNFFzDz9Iapr2jdYze2VbFQrL99H0L//N V2BX2pdNLRY5XVEoIntz5g3+1v96jPlPCYSARAOuVLOScitEPQBZbkde0PKBdloU1vQr F/487juMBhTsA4EVSQ80u+W3g8n2QNNfXOM2TXVVwg2TP0EB+n7yb9uEN2TjIIzB53HP /GZg== X-Gm-Message-State: AOAM533A7HUyEXuejFvX4d3CM+Ei/F02Y6n5JGS6rU9uRoqDq+3OlHR1 N5iiqZTOgRoxKWNWhouFubk1Lt7vMR6qMs/2zuC+FSt3 X-Google-Smtp-Source: ABdhPJyHU6UTsRVwfdUiKEORMnRsfBcRRBXQ7r6ezqwhpc2bTUcbF3aQOHhRvs36u/kleBjYqXhPggxWr1jnGKDi2jE= X-Received: by 2002:a67:1a47:0:b0:332:9c08:8bfa with SMTP id a68-20020a671a47000000b003329c088bfamr5322237vsa.3.1652164217495; Mon, 09 May 2022 23:30:17 -0700 (PDT) MIME-Version: 1.0 References: <20220505050437.86261-1-hongtao.liu@intel.com> In-Reply-To: From: Richard Biener Date: Tue, 10 May 2022 08:30:05 +0200 Message-ID: Subject: Re: [PATCH] Strip of a vector load which is only used partially. To: Jeff Law Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.4 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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2022 06:30:19 -0000 On Tue, May 10, 2022 at 12:58 AM Jeff Law via Gcc-patches wrote: > > > > On 5/5/2022 2:26 AM, Richard Biener via Gcc-patches wrote: > > On Thu, May 5, 2022 at 7:04 AM liuhongt wrote: > >> Optimize > >> > >> _1 = *srcp_3(D); > >> _4 = VEC_PERM_EXPR <_1, _1, { 4, 5, 6, 7, 4, 5, 6, 7 }>; > >> _5 = BIT_FIELD_REF <_4, 128, 0>; > >> > >> to > >> > >> _1 = *srcp_3(D); > >> _5 = BIT_FIELD_REF <_1, 128, 128>; > >> > >> the upper will finally be optimized to > >> > >> _5 = BIT_FIELD_REF <*srcp_3(D), 128, 128>; > >> > >> Bootstrapped and regtested on x86_64-pc-linux-gnu{m32,}. > >> Ok for trunk? > > Hmm, tree-ssa-forwprop.cc:simplify_bitfield_ref should already > > handle this in the > > > > if (code == VEC_PERM_EXPR > > && constant_multiple_p (bit_field_offset (op), size, &idx)) > > { > > > > part of the code - maybe that needs to be enhanced to cover > > a contiguous stride in the VEC_PERM_EXPR. I see > > we have > > > > size = TREE_INT_CST_LOW (TYPE_SIZE (elem_type)); > > if (maybe_ne (bit_field_size (op), size)) > > return false; > > > > where it will currently bail, so adjust that to check for a > > constant multiple. I also think we should only handle the > > case where the new bit_field_offset alignment is not > > worse than the original one. > > > > That said, I'd prefer if you integrate this transform with > > simplify_bitfield_ref. > I've got a hack here that tries to do something similar, but it's trying > to catch the case where we CONSTRUCTOR feeds the BIT_FIELD_REF. It > walks the CONSTRUCTOR elements to see if an element has the right > offset/size to satisify the BIT_FIELD_REF. For x264 we're often able to > eliminate the VEC_PERMUTE entirely and just forward operands into the > BIT_FIELD_REF. > > I was leaning towards moving those bits into match.pd before submitting, > but if you'd prefer them in tree-ssa-forwprop, that's even easier. I think when deciding where to put things it's important to look where related transforms reside. We already do have a (simplify (BIT_FIELD_REF CONSTRUCTOR@ ...)) pattern which should also handle your case already. So instead of adding something new it would be nice to figure why it doesn't handle the case you are interested in and eventually just adjust the existing pattern. In the case of the above patch there isn't a match.pd pattern for this yet but forwprop already has code to match bit-field-refs with vec-perms, so that's the reason I preferred extending that. But of course the whole thing could live in match.pd as well. Richard. > Jeff > >