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
next prev parent 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).