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
