[PATCH 2/8] Introduce vcond_supported_p hook

[Ilya Leoshkevich]

> Am 20.08.2019 um 12:13 schrieb Richard Sandiford <richard.sandiford@arm.com>:
> 
> Ilya Leoshkevich <iii@linux.ibm.com> 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  <iii@linux.ibm.com>
>> 
>> 	* doc/tm.texi (TARGET_VCOND_SUPPORTED_P): Document.
>> 	* doc/tm.texi.in (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.