Re: Use predicates for RTL objects

[Jeff Law <law at redhat dot com>]

On 8/8/19 11:42 AM, Arvind Sankar wrote:
> On Thu, Aug 08, 2019 at 10:04:14AM -0500, Segher Boessenkool wrote:
>> 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.
> 
> That's a matter of what style you prefer and it seems like no-one else
> shares my preference, and I accept that we're not going to make such a
> change.
> 
> But there is really nothing more or less obvious about it. It's easy to
> go look at the code, as you probably once did when checking what
> GET_CODE or REG_P actually did, and is_a methods are expected to be
> lightweight. Regarding hiding things, consider that we just added
> LABEL_REF_P, which is for a comparison that happens less than half as
> often as PLUS in the codebase (and I think it was actually only
> used in one place). It was done presumably because the author/reviewers
> felt that LABEL_REF_P (x) is more readable than GET_CODE (x) == LABEL_REF, 
> even if the latter might be ever so slightly more transparent as to what
> its doing than the former.
I think what Segher is referring to is that GCC developers should know
that GET_CODE is just x->code, ie, a single dereference, similarly for
other RTL/TREE accessors.  A function call (or something that looks like
a function call) has traditionally been reserved for things that are
less performance sensitive and could be doing more work within GCC.

But those are merely conventions and ones that we've had in this project
for 30+ years and are to some degree driven by the C language as it
stood in the 80s.   We're not as strict about those conventions as we've
been in the past, but I don't think we're ready to throw them totally
out the window.

There's nothing *inherently* cheaper about either form.  Both could be
used in either way.

Jeff