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 anyone. > > 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 > them. 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. Segher
