This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: builtin_constant_p
- To: Richard Henderson <rth at cygnus dot com>
- Subject: Re: builtin_constant_p
- From: Jim Wilson <wilson at cygnus dot com>
- Date: Thu, 25 Jun 1998 19:18:06 -0700
- cc: law at cygnus dot com, egcs-patches at cygnus dot com
Speaking of problems that might show up, I built glibc this evening
and discovered that the Alpha didn't have predicates that would match
(set (reg) (constant_p ...))
I went ahead and added it everywhere in the Alpha backend. Others
will have similar problems if they ignore CONSTANT_P.
I suspect many RISC targets will have this problem.
It is a pity that CONST_OK_FOR_LETTER_P takes an integer and not an rtx.
It would nice if you could modify CONST_OK_FOR_LETTER_P to accept
CONSTANT_P_RTX, as we know that will be either 0 or 1. You can then modify
all predicates to use CONST_OK_FOR_LETTER_P, and then you don't need
any explicit checks for CONSTANT_P_RTX in any of the predicates.
Note that if we do install this patch, then we have the immediate problem
that builtin_constant_p no longer works for some targets, which is a bad
idea. We really need something that will work for all targets. Maybe
we conditionally emit CONSTANT_P_RTX if the port has support for it, otherwise
we handle it the old way? You can probably automatically detect this by
generating an insn to load CONSTANT_P_RTX into a pseudo and then trying to
recognize it. Or maybe you need to test all targets before we install the
change?
You also need to fix PREDICATE_CODES in alpha.h to accept CONSTANT_P_RTX.
Just the fact of adding CONSTANT_P_RTX to CONSTANT_P probably will make
a lot of PREDICATE_CODES macros wrong, because anything that accepts
constant operands will be missing CONSTANT_P_RTX. This is harmless if
we never emit CONSTANT_P_RTX for those targets though.
I suspect we will think of more problems as we go along. Adding new basic
RTL codes is hard.
Jim