Re: [PATCH] vect: Handle demoting FLOAT and promoting FIX_TRUNC.

[Richard Biener <richard.guenther@gmail.com>]

On Thu, Jul 13, 2023 at 2:19 PM Robin Dapp <rdapp.gcc@gmail.com> wrote:
>
> > Can you add testcases?  Also the current restriction is because
> > the variants you add are not always correct and I don't see any
> > checks that the intermediate type doesn't lose significant bits?
>
> The testcases I wanted to add with a follow-up RISC-V patch but
> I can also try an aarch64 one.
>
> So for my understanding, please correct, we have:
>
>   promoting int -> float, should always be safe.  We currently
>    vectorize this with WIDEN and NONE.
>
>   demoting float -> int, this is safe as long as the float
>    value can be represented in the int type, otherwise we must
>    trap.
>    We currently vectorize this on x86 using NARROW (regardless
>    of -ftrapping-math) and using NONE only with -fno-trapping-math.
>
>   demoting int -> float, this is safe as long as the
>    intermediate types can hold the initial value?  How is
>    this different to demoting e.g. int64_t -> int8_t?
>    We currently do not vectorize this with either NARROW or NONE.
>    LLVM vectorizes but only with their default(?) -fno-trapping-math.
>    Yet I don't see how we could trap here?
>
>   promoting float -> int, this is safe as long as the float
>    value can be represented (as above)?  We currently vectorize
>    this (regardless of -ftrapping-math) with WIDEN but not NONE.
>
> So apart from unifying the -ftrapping-math behavior I think only
> the third variant is somewhat critical?

I think all demoting cases need checks that are not present right now
irrespective of properly trapping.

Richard.

> Regards
>  Robin
>