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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id D0C713858001 for ; Mon, 14 Dec 2020 20:02:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D0C713858001 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-37-wVRxOZuwNGm_t3NCr-0R7Q-1; Mon, 14 Dec 2020 15:02:09 -0500 X-MC-Unique: wVRxOZuwNGm_t3NCr-0R7Q-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 95028802B40; Mon, 14 Dec 2020 20:02:08 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-227.phx2.redhat.com [10.3.113.227]) by smtp.corp.redhat.com (Postfix) with ESMTP id 52181100164C; Mon, 14 Dec 2020 20:02:08 +0000 (UTC) Subject: Re: [19/23] rtlanal: Add some new helper classes To: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com References: From: Jeff Law Message-ID: Date: Mon, 14 Dec 2020 13:02:07 -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.84 on 10.5.11.22 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=-5.4 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_H3, 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, 14 Dec 2020 20:02:15 -0000 On 12/14/20 9:37 AM, Richard Sandiford wrote: > Jeff Law writes: >> On 11/13/20 1:20 AM, Richard Sandiford via Gcc-patches wrote: >>> This patch adds some classes for gathering the list of registers >>> and memory that are read and written by an instruction, along >>> with various properties about the accesses. In some ways it's >>> similar to the information that DF collects for registers, >>> but extended to memory. The main reason for using it instead >>> of DF is that it can analyse tentative changes to instructions >>> before they've been committed. >>> >>> The classes also collect general information about the instruction, >>> since it's cheap to do and helps to avoid multiple walks of the same >>> RTL pattern. >>> >>> I've tried to optimise the code quite a bit, since with later patches >>> it becomes relatively performance-sensitive. See the discussion in >>> the comments for the trade-offs involved. >>> >>> I put the declarations in a new rtlanal.h header file since it >>> seemed a bit excessive to put so much new inline stuff in rtl.h. >>> >>> gcc/ >>> * rtlanal.h: New file. >>> (MEM_REGNO): New constant. >>> (rtx_obj_flags): New namespace. >>> (rtx_obj_reference, rtx_properties): New classes. >>> (growing_rtx_properties, vec_rtx_properties_base): Likewise. >>> (vec_rtx_properties): New alias. >>> * rtlanal.c: Include it. >>> (rtx_properties::try_to_add_reg): New function. >>> (rtx_properties::try_to_add_dest): Likewise. >>> (rtx_properties::try_to_add_src): Likewise. >>> (rtx_properties::try_to_add_pattern): Likewise. >>> (rtx_properties::try_to_add_insn): Likewise. >>> (vec_rtx_properties_base::grow): Likewise. >> One might argue at least some of these should become first class >> properties of insns but then we have the joy of keeping them up-to-date >> as transformations are made.  It also reminds me a bit of the old >> var_ann stuff we had in the tree SSA implementation.  > Yeah. The RTL SSA insn info does store these properties, but that has > the advantage of being new code and so can require all updates to go > through new interfaces. I agree that ideally we'd store the information > directly in RTL insns instead. I guess it's less problematic since we're using real classes.  The old annotation stuff was done before we had C++ & classes. > > I guess one question is where we would store the new flags. In some > ways it might be easier to do that after any future split of rtx_insn > and rtx, since we could then use a smaller code field and potentially > replace the mode field. (Things like :TI markers for VLIW bundles > could use a separate flag instead.) Dunno offhand.  I'm OK with things as-is for now -- again, having classes allows us to real wrappers and enforce a degree to access control, which greatly diminishes the pain we had with var_ann. Splitting off rtx_insn from rtx is independent, but definitely something I want to see move forward. Jeff