From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-199872-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 115812 invoked by alias); 9 Aug 2019 08:06:32 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 115803 invoked by uid 89); 9 Aug 2019 08:06:32 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=isah
X-HELO: mail-lj1-f171.google.com
Received: from mail-lj1-f171.google.com (HELO mail-lj1-f171.google.com) (209.85.208.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Aug 2019 08:06:31 +0000
Received: by mail-lj1-f171.google.com with SMTP id k18so91251518ljc.11        for <gcc@gcc.gnu.org>; Fri, 09 Aug 2019 01:06:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=gmail.com; s=20161025;        h=mime-version:references:in-reply-to:from:date:message-id:subject:to         :cc;        bh=Eke2MNsL47231oS4K/0+WaIhkObk82pDJl6F1F56Ebo=;        b=S3OqTCJN2LgllWtxVyRZ82eXkEKuo9sMfmIyR3N+mRBUH3YpfNXVcj5fD55hZee/2K         BRiYgl3sBWuEeLHIP4Wbyr4gdqNH2A/8ZtfsHgVk88gqTufN9b5SnG648MOTSdq0jdDE         CQoRWL4gl1TTQkYalckb8esUHJzkY05GtGSPcuZbWA0YdW402rGbjr01g1HyrBozT0zU         FmfZY4Jg6e0e7hdoLKSPV4VZ0Q4g+CBKoZEWmGbi4b4Sp974PUX56CSwRNCuXdEIAEcb         YKVzPfNCu4IEwDD/dYeqi4WWZ4Xo1C7i3/BRuF7YUx1+2QvXjrTlGy6nMJqvBycMeGqm         u4VA==
MIME-Version: 1.0
References: <20190807161528.GA3326377@rani.riverdale.lan> <20190807173353.GV31406@gate.crashing.org>
In-Reply-To: <20190807173353.GV31406@gate.crashing.org>
From: Richard Biener <richard.guenther@gmail.com>
Date: Fri, 09 Aug 2019 08:06:00 -0000
Message-ID: <CAFiYyc3v2+Bb8trpiqnt0jzXswU-aUt5RpgYh-DH8EY16Ru8JQ@mail.gmail.com>
Subject: Re: Use predicates for RTL objects
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>, GCC Development <gcc@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-IsSubscribed: yes
X-SW-Source: 2019-08/txt/msg00066.txt.bz2

On Wed, Aug 7, 2019 at 7:34 PM Segher Boessenkool
<segher@kernel.crashing.org> 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.
>
> 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!
>
> (And "REG_P" and similar are much shorter code to type).

Note also that in other places in GCC we use

  is_a <REG> (x)

instead, see is-a.h.  I don't welcome your member-function style style :/

Richard.

>
> Segher