On Thu, Aug 08, 2019 at 01:42:40PM -0400, Arvind Sankar wrote: > On Thu, Aug 08, 2019 at 10:04:14AM -0500, Segher Boessenkool wrote: > But there is really nothing more or less obvious about it.
That depends on what you are used to seeing, a lot. > It's easy to > go look at the code, as you probably once did when checking what > GET_CODE or REG_P actually did, It's in the documentation as well, and there are examples every tenth line of code to look at. > 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. LABEL_REF_P works out nicely because it is referring to something that is data, is not an operator. "Leaves" in an RTL expression, if you want to look at it that way. Predicates for other RTX codes aren't always as obvious, see CONST_P as example. PLUS_P would be a bit borderline. Part of the reason why REG_P and MEM_P and the like are nice, is that these predicates are often used in bigger conditions, maybe together with some XEXP and whatnot. Is that the case for PLUS_P? > > Indirection is *the* evil in programming. > > Some would say that "All problems in computer science can be solved by > another level of indirection" ;) Yes, and that is the problem. :-P Indirection doesn't solve problems, it just hides them. Diluting your code does not make it simpler, quite the opposite; it just makes it hard to spot the problem parts. Segher
