This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Use predicates for RTL objects
- From: Arvind Sankar <nivedita at alum dot mit dot edu>
- To: gcc at gcc dot gnu dot org
- Date: Wed, 7 Aug 2019 12:15:29 -0400
- Subject: Use predicates for RTL objects
Hi,
I have posted a patch series [1] for converting some of the RTL code to
use predicate macros, as described in the suggestions for beginner GCC
projects [2]. Segher was kind enough to give some comments on the
initial posting [3].
The code has been bootstrapped natively on x86_64, and I have built
cross-compilers for all targets except tilegx which gave build errors
even on trunk. The compiler object files are identical with trunk except
for *-checksum.o and string tables in build/gen*.o which change from
GET_CODE (..) == .. etc to the predicate macro.
Not all possible changes have been made yet, I figured I'd send this out
to check first.
I am hoping one of the maintainers will be able to take some time to
review the patches -- a few are quite large but are mechanical.
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)
More complex predicates could be left as macros or additional methods
could be defined like rtx_def::is_a_nondebug_insn etc. I think this
should mostly be an improvement, although the comparisons around INSN
may become slightly more confusing: currently, INSN_P (x) is different
from is_a <rtx_insn *> (x), and using something like x->is_a_insn () for
the former would probably increase confusion.
Thanks.
[1] https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00327.html
[2] https://gcc.gnu.org/projects/beginner.html
[3] https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00171.html