This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: define_predicate, revised (1/2)


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
if_then_else form).

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.

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]