From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id E9F5B3844026 for ; Mon, 30 Nov 2020 20:03:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E9F5B3844026 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-552-WerGThIPNvyLbJQkeDIK6w-1; Mon, 30 Nov 2020 15:03:22 -0500 X-MC-Unique: WerGThIPNvyLbJQkeDIK6w-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A04F963CDC; Mon, 30 Nov 2020 20:03:21 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-145.phx2.redhat.com [10.3.112.145]) by smtp.corp.redhat.com (Postfix) with ESMTP id 601C15D9C0; Mon, 30 Nov 2020 20:03:21 +0000 (UTC) Subject: Re: [15/23] recog: Add a validate_change_xveclen function To: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com References: From: Jeff Law Message-ID: <8f2ab8c2-f978-66cf-00f8-6d4e2c27da06@redhat.com> Date: Mon, 30 Nov 2020 13:03:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Mon, 30 Nov 2020 20:03:26 -0000 On 11/13/20 1:19 AM, Richard Sandiford via Gcc-patches wrote: > A later patch wants to be able to use the validate_change machinery > to reduce the XVECLEN of a PARALLEL. This should be more efficient > than allocating a separate PARALLEL at a possibly distant memory > location, especially since the new PARALLEL would be garbage rtl if > the new pattern turns out not to match. Combine already pulls this > trick with SUBST_INT. > > This patch adds a general helper for doing that. > > gcc/ > * recog.h (validate_change_xveclen): Declare. > * recog.c (change_t::old_len): New field. > (validate_change_1): Add a new_len parameter. Conditionally > replace the XVECLEN of an rtx, avoiding single-element PARALLELs. > (validate_change_xveclen): New function. > (cancel_changes): Undo changes made by validate_change_xveclen. OK. Presumably it's better to reduce the length of the existing vector, possibly losing a bit of memory off the end rather than releasing the existing vector and allocating a new one of the desired length (as you say it'd likely have no good locality). And note that when I say lose, I mean lose the ability to use those slots after we shrink the vector (say if we later wanted to lengthen it).  The memory doesn't actually leak as it'll be released if we ever release the vector. Jeff