From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 91BB53858285 for ; Wed, 28 Sep 2022 09:43:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 91BB53858285 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CC70C1063; Wed, 28 Sep 2022 02:43:17 -0700 (PDT) Received: from [10.1.29.159] (E121495.arm.com [10.1.29.159]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 942513F792; Wed, 28 Sep 2022 02:43:10 -0700 (PDT) Message-ID: <42e266bd-7224-76b7-c782-c00063531917@arm.com> Date: Wed, 28 Sep 2022 10:43:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Subject: Re: [PATCH] Teach vectorizer to deal with bitfield accesses (was: [RFC] Teach vectorizer to deal with bitfield reads) Content-Language: en-US To: Richard Biener Cc: Jakub Jelinek , Richard Sandiford , "gcc-patches@gcc.gnu.org" References: <4a6f2350-f070-1473-63a5-3232968d3a89@arm.com> <4ea91767-de43-9d30-5bd2-a9a0759760c7@arm.com> <69abe824-94f5-95b5-fb7f-6fa076973e05@arm.com> <8f805fb1-d4ae-b0e3-ff26-57fd2c1fc1f7@arm.com> <5c3e3af5-c502-fd5a-2792-4e0d1db405ef@arm.com> From: "Andre Vieira (lists)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-16.3 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,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 27/09/2022 13:34, Richard Biener wrote: > On Mon, 26 Sep 2022, Andre Vieira (lists) wrote: > >> On 08/09/2022 12:51, Richard Biener wrote: >>> I'm curious, why the push to redundant_ssa_names? That could use >>> a comment ... >> So I purposefully left a #if 0 #else #endif in there so you can see the two >> options. But the reason I used redundant_ssa_names is because ifcvt seems to >> use that as a container for all pairs of (old, new) ssa names to replace >> later. So I just piggy backed on that. I don't know if there's a specific >> reason they do the replacement at the end? Maybe some ordering issue? Either >> way both adding it to redundant_ssa_names or doing the replacement inline work >> for the bitfield lowering (or work in my testing at least). > Possibly because we (in the past?) inserted/copied stuff based on > predicates generated at analysis time after we decide to elide something > so we need to watch for later appearing uses. But who knows ... my mind > fails me here. > > If it works to replace uses immediately please do so. But now > I wonder why we need this - the value shouldn't change so you > should get away with re-using the existing SSA name for the final value? Yeah... good point. A quick change and minor testing seems to agree. I'm sure I had a good reason to do it initially ;) I'll run a full-regression on this change to make sure I didn't miss anything.