This is the mail archive of the 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: [PATCH 2/8] Introduce vcond_supported_p hook

> Am 20.08.2019 um 12:13 schrieb Richard Sandiford <>:
> Ilya Leoshkevich <> writes:
>> z13 supports only non-signaling vector comparisons.  This means we
>> cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13.
>> However, we cannot express this restriction today: the code only checks
>> whether vcond$a$b optab, which does not contain information about the
>> operation.
>> Introduce a hook that tells whether target supports certain vector
>> comparison operations with certain modes.
>> gcc/ChangeLog:
>> 2019-08-09  Ilya Leoshkevich  <>
>> 	* doc/tm.texi (TARGET_VCOND_SUPPORTED_P): Document.
>> 	* doc/ (TARGET_VCOND_SUPPORTED_P): Document.
>> 	* optabs-tree.c (expand_vec_cond_expr_p): Use vcond_supported_p
>> 	in addition to get_vcond_icode.
>> 	* target.def (vcond_supported_p): New hook.
>> 	* targhooks.c (default_vcond_supported_p): Likewise.
>> 	* targhooks.h (default_vcond_supported_p): Likewise.
> IMO it'd be cleaner to have a new optabs-query.[hc] helper that uses
> the predicate for operand 3 to test whether a particular comparison
> is supported.  I guess this would require a cached rtx to avoid
> generating too much garbage rtl though (via GTY((cache))).

How can I implement such a predicate?  Would calling maybe_gen_insn with
a fake rtx be reasonable?  In this case, what would be the best way to
generate fake input operands?  The existing code that calls
maybe_gen_insn gets the corresponding rtxes from upper layers.

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