This is the mail archive of the
mailing list for the GCC project.
Re: Use predicates for RTL objects
On Wed, Aug 07, 2019 at 01:39:53PM -0400, Arvind Sankar wrote:
> On Wed, Aug 07, 2019 at 12:33:53PM -0500, Segher Boessenkool wrote:
> > On Wed, Aug 07, 2019 at 12:15:29PM -0400, Arvind Sankar wrote:
> > > I would also like to get some comments on the following idea to make the
> > > code checks more readable: I am thinking of adding
> > > bool rtx_def::is_a (enum rtx_code) const
> > > This would allow us to make all the rtx_code comparisons more readable
> > > without having to define individual macros for each.
> > > i.e.,
> > > REG_P (x) => x->is_a (REG)
> > > GET_CODE (x) == PLUS => x->is_a (PLUS)
> > > GET_CODE (PATTERN (x)) == SEQUENCE => PATTERN (x)->is_a (SEQUENCE)
> > That makes things much worse. Not only is it less readable (IMO), but
> > the "is_a" idiom is used to check if something is of a certain class,
> > which is not the case here.
> Well, the rtx_code *is* kind of a class. It determines what fields of
> the rtx are valid and what they contain etc.
It is not a class in the C++ sense. Confusing this is not useful for
> > In "GET_CODE (x) == PLUS" it is clear that what the resulting machine
> > code does is cheap. With "x->is_a (PLUS)", who knows what is happening
> > below the covers!
> We already have, for eg, is_a <rtx_sequence *> (x), and there are
Whis *is* a class. And not all of us are happy with that, but since we
don't often have to see it at all, it's not so bad.
Having rtx_insn a separate type from rtx is actually useful, btw.
> predicate macros whose implementation is more complex than checking the
> code field. You basically have to trust that it's sensibly implemented,
> i.e. that it is as efficiently implemented as it can be.
That's not my point -- my point was that it is *obvious* the way things
are now, which is nice.
> 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.
> > (And "REG_P" and similar are much shorter code to type).
> That is true for the ones that exist, but there are lots more that don't
> and it doesn't really make sense to add individual macros for all of
Yes. So use GET_CODE for those? REG_P is super frequent, it is really
handy to have a macro for it.
If you really want to convert RTL to C++, you should start with getting
rid of rtx_format and rtx_class, and make REG_P etc. work just as they
have always done.