[Bug c/111794] RISC-V: Missed SLP optimization due to mask mode precision

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111794

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 16 Oct 2023, rdapp at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111794
> 
> --- Comment #5 from Robin Dapp <rdapp at gcc dot gnu.org> ---
> Disregarding the reasons for the precision adjustment, for this case here, we
> seem to fail at:
> 
>   /* We do not handle bit-precision changes.  */
>   if ((CONVERT_EXPR_CODE_P (code)
>        || code == VIEW_CONVERT_EXPR)
>       && ((INTEGRAL_TYPE_P (TREE_TYPE (scalar_dest))
>            && !type_has_mode_precision_p (TREE_TYPE (scalar_dest)))
>           || (INTEGRAL_TYPE_P (TREE_TYPE (op))
>               && !type_has_mode_precision_p (TREE_TYPE (op))))
>       /* But a conversion that does not change the bit-pattern is ok.  */
>       && !(INTEGRAL_TYPE_P (TREE_TYPE (scalar_dest))
>            && INTEGRAL_TYPE_P (TREE_TYPE (op))
>            && (TYPE_PRECISION (TREE_TYPE (scalar_dest))
>                > TYPE_PRECISION (TREE_TYPE (op)))
>            && TYPE_UNSIGNED (TREE_TYPE (op))))
>     {
>       if (dump_enabled_p ())
>         dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
>                          "type conversion to/from bit-precision "
>                          "unsupported.\n");
>       return false;
>     }
> 
> for the expression
>  patt_156 = (<signed-boolean:1>) _2;
> where _2 (op) is of type _Bool (i.e. TYPE_MODE QImode) and patt_156
> (scalar_dest) is signed-boolean:1.  In that case the mode's precision (8) does
> not match the type's precision (1) for both op and _scalar_dest.
> 
> The second part of the condition I don't fully get.  When does a conversion
> change the bit pattern?  When the source has higher precision than the dest we
> would need to truncate which we probably don't want.  When the dest has higher
> precision that's considered ok?  What about equality?
> 
> If both op and dest have precision 1 the padding could differ (or rather the 1
> could be at different positions) but do we even support that?  In other words,
> could we relax the condition to TYPE_PRECISION (TREE_TYPE (scalar_dest)) >=
> TYPE_PRECISION (TREE_TYPE (op)) (>= instead of >)?
> 
> FWIW bootstrap and testsuite unchanged with >= instead of > on x86, aarch64 and
> power10 but we might not have a proper test for that?

It's about sign- vs. zero-extending into padding.  What kind of code
does the vectorizer emit?