builtin_constant_p

Jim Wilson wilson@cygnus.com
Thu Jun 25 19:18:00 GMT 1998


	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



More information about the Gcc-patches mailing list