From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7783 invoked by alias); 7 Aug 2019 18:05:57 -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 7775 invoked by uid 89); 7 Aug 2019 18:05:57 -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=worried, handy, *is*, 53pm 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; Wed, 07 Aug 2019 18:05:56 +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 x77I5qhX020656; Wed, 7 Aug 2019 13:05:52 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x77I5pLX020655; Wed, 7 Aug 2019 13:05:51 -0500 Date: Wed, 07 Aug 2019 18:05:00 -0000 From: Segher Boessenkool To: Arvind Sankar Cc: gcc@gcc.gnu.org Subject: Re: Use predicates for RTL objects Message-ID: <20190807180551.GX31406@gate.crashing.org> References: <20190807161528.GA3326377@rani.riverdale.lan> <20190807173353.GV31406@gate.crashing.org> <20190807173952.GA3751941@rani.riverdale.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190807173952.GA3751941@rani.riverdale.lan> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00027.txt.bz2 On Wed, Aug 07, 2019 at 01:39:53PM -0400, Arvind Sankar wrote: > On Wed, Aug 07, 2019 at 12:33:53PM -0500, Segher Boessenkool wrote: > > On Wed, Aug 07, 2019 at 12:15:29PM -0400, Arvind Sankar wrote: > > > I would also like to get some comments on the following idea to make the > > > code checks more readable: I am thinking of adding > > > bool rtx_def::is_a (enum rtx_code) const > > > This would allow us to make all the rtx_code comparisons more readable > > > without having to define individual macros for each. > > > i.e., > > > REG_P (x) => x->is_a (REG) > > > GET_CODE (x) == PLUS => x->is_a (PLUS) > > > GET_CODE (PATTERN (x)) == SEQUENCE => PATTERN (x)->is_a (SEQUENCE) > > > > That makes things much worse. Not only is it less readable (IMO), but > > the "is_a" idiom is used to check if something is of a certain class, > > which is not the case here. > > Well, the rtx_code *is* kind of a class. It determines what fields of > the rtx are valid and what they contain etc. It is not a class in the C++ sense. Confusing this is not useful for anyone. > > In "GET_CODE (x) == PLUS" it is clear that what the resulting machine > > code does is cheap. With "x->is_a (PLUS)", who knows what is happening > > below the covers! > > 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. Having rtx_insn a separate type from rtx is actually useful, btw. > predicate macros whose implementation is more complex than checking the > code field. You basically have to trust that it's sensibly implemented, > i.e. that it is as efficiently implemented as it can be. That's not my point -- my point was that it is *obvious* the way things are now, which is nice. > I don't think > people writing RTL transformations should be overly worried about what > machine code their predicates are generating, especially when > they're calling the defined API for it. The whole *design* of RTL is based around us caring a whole lot. > > (And "REG_P" and similar are much shorter code to type). > > That is true for the ones that exist, but there are lots more that don't > and it doesn't really make sense to add individual macros for all of > them. Yes. So use GET_CODE for those? REG_P is super frequent, it is really handy to have a macro for it. 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. Segher