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

[Robin Dapp <rdapp.gcc@gmail.com>]

> 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?

Regards
 Robin