This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: altivec predicates
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 2 Feb 2002 09:58:14 +1100
- Subject: Re: altivec predicates
> Is it really wise for the __builtin_altivec_predicate_MODE
> functions to have the actual assembler mnemonic which GCC will use to
> substitute in the assembly stream as an argument (e.g., "*vcmpbfp.")?
> It's sort of like inlined assembly without using __asm__. Nothing
probably not the prettiest, but we have documented the fact that these
builtins are not supported at all. another approach would be to
have
__builtin_altivec_predicate_vcmpequw_eq
__builtin_altivec_predicate_vcmpequw_eq_rev
__builtin_altivec_predicate_vcmpequw_lt
__builtin_altivec_predicate_vcmpequw_lt_rev
multiply that by the different vcmp*. compare instructions.
so we'll end up with about 60 (?) extra builtins. it's just
too much work, i think.
> Also, predicate seems like a bad choice of names. In PowerPC the
> appended period on mnemonics is the Record Condition bit which sets a
> predefined condition register to represent a comparing the instruction's
> result with zero. Integer instructions set cr0, Floating Point
> instructions set cr1. Altivec has expanded this to set cr6 for Altivec
> instructions, in addition to the mask specified as the output operand.
what do you suggest? i'm using predicate because that is what the
motorola altivec specs call them.
i will hold off committing until the above is addressed.
thx.
--
Aldy Hernandez E-mail: aldyh@redhat.com
Professional Gypsy Lost in Australia
Red Hat, Inc.