public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Arvind Sankar <nivedita@alum.mit.edu>
Cc: gcc@gcc.gnu.org
Subject: Re: Use predicates for RTL objects
Date: Thu, 08 Aug 2019 15:04:00 -0000	[thread overview]
Message-ID: <20190808150414.GD31406@gate.crashing.org> (raw)
In-Reply-To: <20190807185810.GA3777497@rani.riverdale.lan>

On Wed, Aug 07, 2019 at 02:58:12PM -0400, Arvind Sankar wrote:
> > > > code does is cheap.  With "x->is_a (PLUS)", who knows what is happening
> > That's not my point -- my point was that it is *obvious* the way things
> > are now, which is nice.
> 
> My reply is pointing out that it is just as (non-)obvious with or
> without that inline function, if you want to use any of the helper
> macros.

But that is not what you suggested, or at least not how I read it.
  x->is_a (PLUS)
is not obviously cheap or simple at all, while
  GET_CODE (x) == PLUS
obviously *is*.

The former also isn't readable.

Indirection is *the* evil in programming.

All the common stuff that can be easily hidden behind macros, sure,
but we're not talking only about that.  And if macros have non-trivial
implementations, they shouldn't be macros (but inlines), or maybe
shouldn't even exist at all.

> > > 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.
> 
> I'm not saying that we don't care about performance.

That is now what I said, either.  Performance is only one aspect of
simplicity.


Segher

  reply	other threads:[~2019-08-08 15:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-07 16:15 Arvind Sankar
2019-08-07 17:33 ` Segher Boessenkool
2019-08-07 17:40   ` Arvind Sankar
2019-08-07 18:05     ` Segher Boessenkool
2019-08-07 18:58       ` Arvind Sankar
2019-08-08 15:04         ` Segher Boessenkool [this message]
2019-08-08 17:42           ` Arvind Sankar
2019-08-08 18:26             ` Segher Boessenkool
2019-08-08 18:53               ` Arvind Sankar
2019-08-08 20:28             ` Jeff Law
2019-08-08  9:10       ` Richard Sandiford
2019-08-08 15:28         ` Segher Boessenkool
2019-08-08 14:31       ` Jeff Law
2019-08-08 15:36         ` Segher Boessenkool
2019-08-08 17:07         ` Arvind Sankar
2019-08-08 20:11           ` Jeff Law
2019-08-09  8:06   ` Richard Biener
2019-08-08 15:04 ` Michael Matz
2019-08-08 17:12   ` Arvind Sankar
2019-08-08 18:14     ` Jakub Jelinek
2019-08-08 18:35       ` Arvind Sankar
2019-08-08 18:46         ` Jakub Jelinek
2019-08-08 20:32           ` Jeff Law
  -- strict thread matches above, loose matches on Subject: below --
2006-02-03  4:23 nathan bullock
2006-02-03  5:46 ` Ben Elliston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190808150414.GD31406@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=gcc@gcc.gnu.org \
    --cc=nivedita@alum.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).