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. > 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 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. 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. > > (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. > > Segher
