From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56784 invoked by alias); 8 Aug 2019 15:28:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 56776 invoked by uid 89); 8 Aug 2019 15:28:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*i:sk:mpth86s, H*f:sk:mpth86s X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Aug 2019 15:28:40 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x78FSVWh008646; Thu, 8 Aug 2019 10:28:31 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x78FSUId008645; Thu, 8 Aug 2019 10:28:30 -0500 Date: Thu, 08 Aug 2019 15:28:00 -0000 From: Segher Boessenkool To: Arvind Sankar , gcc@gcc.gnu.org, richard.sandiford@arm.com Subject: Re: Use predicates for RTL objects Message-ID: <20190808152830.GE31406@gate.crashing.org> References: <20190807161528.GA3326377@rani.riverdale.lan> <20190807173353.GV31406@gate.crashing.org> <20190807173952.GA3751941@rani.riverdale.lan> <20190807180551.GX31406@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00037.txt.bz2 On Thu, Aug 08, 2019 at 10:10:38AM +0100, Richard Sandiford wrote: > Segher Boessenkool writes: > > On Wed, Aug 07, 2019 at 01:39:53PM -0400, Arvind Sankar wrote: > >> We already have, for eg, is_a (x), and there are > > > > Whis *is* a class. And not all of us are happy with that, but since we > > don't often have to see it at all, it's not so bad. > > Speaking as someone who is happy about that[*]... > > [*] ...at least in principle. It isn't really a proper class yet > because we don't construct rtx sequences as rtx_sequence objects, > we just access them that way. I was a bit surprised that this > was defined behaviour... _In principle_, sure, I have nothing against C++ conversions if it has advantages that outweigh their disadvantages. > > If you really want to convert RTL to C++, you should start with getting > > rid of rtx_format and rtx_class, and make REG_P etc. work just as they > > have always done. > > I don't think getting rid of rtx_format and rtx_class should > necessarily be the first step. The base class can still provide > the traditional accessors (with runtime checking when enabled). It is *the* core thing that needs to be changed if you want this to be any other than pointless uglification. Those two RTX fields are the core of how it works now. If you want to use C++ classes, instead, you need to replace them with some suitable C++ thing. And we need to see that design before we can say if it looks acceptable at all. > Another option would be to start adding derived classes for certain > types of rtx, and actually constructing those types of rtx with the > appropriate type. It'd probably make sense to start with special- > purposes rtxes like ADDRESS, DEBUG_IMPLICIT_PTR or SYMBOL_REF (which > is already somewhat special). I would prefer to see an overall design before making partial changes. > IMO the advantages of using a proper class hierarchy would be: > > - More static type checking. Runtime RTL checking is still seen as too > expensive to enable by default even in development builds, so RTL goes > unchecked most of the time. Many people enable it all the time. It isn't so expensive compared to other things. --enable-checking=yes,rtl,tree saves more time than it costs, ime, and "rtl" is not the most expensive in that. > - More efficient layouts, rather than forcing every piece of information > outside the header to be in a pointer-sized field. ... and then the GC has to be tuned again. Oh joy. Well, it probably is much detuned already, but :-) It would be nice to see real numbers how much memory this would save, and what that means for compiler runtime. Segher