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: altivec predicates


2002-01-31  Aldy Hernandez  <aldyh@redhat.com>

	* doc/extend.texi: Warn about unsupported usage of altivec
	builtins.

	* config/rs6000/rs6000.md (altivec_vcmp*_p): Remove.
	(altivec_predicate_*): New.
	(cr6_test_for_*): New.

	* config/rs6000/rs6000.h (rs6000_builtins): Add
	ALTIVEC_BUILTIN_PREDICATE_*.
	(rs6000_builtins): Remove _p predicates.

	* config/rs6000/altivec.h: Rewrite predicates to use new builtins.

	* config/rs6000/rs6000.c (bdesc_altivec_preds): New.
	(bdesc_2arg): Remove altivec predicates.
	(altivec_expand_builtin): Handle predicates.
	(altivec_init_builtins): Handle predicates.
	(altivec_expand_predicate_builtin): New.

I guess this is okay.

	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
verifies that the user has not substituted some other instruction which
could do anything.  When inlined assembler is used, all bets are off.  But
do we want the same potential problem from using __builtin?

	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.

David


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