This is the mail archive of the
mailing list for the GCC project.
Re: define_predicate, revised (1/2)
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Richard Henderson <rth at twiddle dot net>, Joern Rennecke <amylaar at spamcop dot net>, paolo dot bonzini at polimi dot it
- Date: Thu, 12 Aug 2004 10:01:21 +0100
- Subject: Re: define_predicate, revised (1/2)
- References: <email@example.com>
On Wed, 2004-08-11 at 19:16, Zack Weinberg wrote:
> There is a third kind of predicate, an "operation predicate", which
> ia64 does not use and frankly I'm not clear on what they're for. So
> I'm not sure whether this mechanism can handle them. Comments from
> folks who maintain targets that do use these would be appreciated; I
> know ARM does, for instance.
I assume you are talking about 'match_operator' here.
That's pretty much essential on the ARM as things stand -- it allows us
to keep the number of patterns in the machine description under control.
Match_operator allows us to match, say, all arithmetic operations with a
single pattern. That wouldn't be particularly important if it weren't
for the fact that it allows us to match all such operations with a
shifted argument with a single pattern.
Now we have 5 operations that are matched by an arithmetic opcode (ADD,
MINUS, AND, IOR, XOR), and each takes 5 possible codes in the shift
position (ASHIFT, ASHIFTRT, LSHIFTRT, ROTATERT and (with a bit of
hacking) MULT by any constant power of 2 -- there are times when I hate
canonicalization). So we now have a single pattern that can match 25
possible combinations of arithmetic and shift.
That gets even more important when you realise that we have to do this
two or three times (at least) to handle conditional execution (in the
It's possible that we could do it another way, for example by
autogenerating the patterns from meta rules, but I'm not sure that the
result would be any more efficient.