This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Use predicates for RTL objects


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]