On 18/11/2021 11:05, Richard Biener wrote:
@@ -3713,12 +3713,21 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
trapping behaviour, so require !flag_trapping_math. */
#if GIMPLE
(simplify
- (float (fix_trunc @0))
- (if (!flag_trapping_math
- && types_match (type, TREE_TYPE (@0))
- && direct_internal_fn_supported_p (IFN_TRUNC, type,
- OPTIMIZE_FOR_BOTH))
- (IFN_TRUNC @0)))
+ (float (fix_trunc@1 @0))
+ (if (types_match (type, TREE_TYPE (@0)))
+ (if (TYPE_SIGN (TREE_TYPE (@1)) == SIGNED
+ && direct_internal_fn_supported_p (IFN_FTRUNC_INT, type,
+ TREE_TYPE (@1),
OPTIMIZE_FOR_BOTH))
+ (with {
+ tree int_type = TREE_TYPE (@1);
+ unsigned HOST_WIDE_INT max_int_c
+ = (1ULL << (element_precision (int_type) - 1)) - 1;
That's only half-way supporting vector types I fear - you use
element_precision but then build a vector integer constant
in an unsupported way. I suppose vector support isn't present
for arm? The cleanest way would probably be to do
tree int_type = element_type (@1);
with providing element_type in tree.[ch] like we provide
element_precision.
This is a good shout and made me think about something I hadn't
before... I thought I could handle the vector forms later, but the
problem is if I add support for the scalar, it will stop the vectorizer.
It seems vectorizable_call expects all arguments to have the same type,
which doesn't work with passing the integer type as an operand work around.
Should I go back to two separate IFN's, could still have the single optab.
Regards,
Andre
