This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: define_predicate, revised (1/2)
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Richard Earnshaw <rearnsha at arm 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:20:24 -0700
- Subject: Re: define_predicate, revised (1/2)
- References: <87wu05pmju.fsf@codesourcery.com><1092301281.28853.1359.camel@pc960.cambridge.arm.com>
Richard Earnshaw <rearnsha@arm.com> writes:
> 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.
Er, no. I'm confident my patch handles match_operator just fine.
What I'm talking about is the predicates you use with
'match_parallel'. ARM's got a lot of those, too. And it's not that
you can't move them over - load_multiple_operation, say, would become
(define_special_predicate "load_multiple_operation"
(match_code "parallel")
{
// body of existing load_multiple_operation function here
})
But that isn't really _better_.
zw