This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Maybe expand MAX_RECOG_ALTERNATIVES ?
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Greg McGary <greg dot mcgary at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 30 May 2012 09:23:46 -0400 (EDT)
- Subject: Re: Maybe expand MAX_RECOG_ALTERNATIVES ?
- References: <4FAD9A11.2030901@gmail.com> <4FADB97A.3020002@gmail.com>
On Fri, 11 May 2012, Greg McGary wrote:
> On 05/11/12 16:00, Greg McGary wrote:
>
> > My question is this: does it make sense to double MAX_RECOG_ALTERNATIVES so
> > that I can use insn attributes to identify operand signatures, or should I use
> > another approach?
>
> After some exploration, I don't see that another approach is even possible. The
> predicates in define_insn_reservation must be statically evaluated by genattrtab,
> so I can't use (match_test "...") or (symbol_ref "..."), where "..." is arbitrary
> C code. Is it true that define_insn_reservation predicates can only use boolean
> expressions on (eq_attr ...), or am I missing something?
Seeing this hasn't been replied to yet, I can't help but stating
the obvious: handle it like MAX_RECOG_OPERANDS. Trivially, just
count the commas (the alternatives) in define_insn and friends.
(I don't think commas are allowed in constraints; if they are,
you may have to restrict the new max to targets using
define_constraint and friends and let the others stay with 30.)
Patches are welcome but be prepared for a lengthy ping session
as always. :/
brgds, H-P