On Thu, Jul 13, 2023 at 2:19 PM Robin Dapp <rdapp....@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 >
