On Mon, 22 Nov 2021, Andre Vieira (lists) wrote:
>
> 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.
We already special case some IFNs there (masked load/store and gather)
to ignore some args, so that would just add to this set.
Richard.
