Re: [AArch64] Enable generation of FRINTNZ instructions

["Andre Vieira (lists)" <andre.simoesdiasvieira@arm.com>]

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