No, I am just want to whether we have some CALL vectorization need len or mask predication.
For example, Current GCC vectorization CALL onyl FMAX/FMIN/FMA/FNMA/FMS/FNMS these CALL function need length or mask predicate. I don't care about sin/cos/popcount...etc. We just use full vector autovectorization is fine, no need to support RVV into middle-end. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-07-13 22:32 To: Palmer Dabbelt; gcc-patches CC: rdapp.gcc; richard.guenther; juzhe.zhong; Kito Cheng; kito.cheng Subject: Re: [PATCH V7] RISC-V: RISC-V: Support gather_load/scatter RVV auto-vectorization >>>> From my understanding, we dont have RVV instruction for fmax/fmin? > > Unless I'm misunderstanding, we do. The ISA manual says > > === Vector Floating-Point MIN/MAX Instructions > > The vector floating-point `vfmin` and `vfmax` instructions have the > same behavior as the corresponding scalar floating-point instructions > in version 2.2 of the RISC-V F/D/Q extension: they perform the > `minimumNumber` > or `maximumNumber` operation on active elements. > > ---- > # Floating-point minimum > vfmin.vv vd, vs2, vs1, vm # Vector-vector > vfmin.vf vd, vs2, rs1, vm # vector-scalar > > # Floating-point maximum > vfmax.vv vd, vs2, vs1, vm # Vector-vector > vfmax.vf vd, vs2, rs1, vm # vector-scalar > ---- > > so we should be able to match at least some loops. We're already emitting those (e.g. for a[i] = a[i] > b[i] ? a[i] : b[i]) but for fmin/fmax they are not wired up yet (as opposed to the scalar variants). Juzhe are you referring to something else? I mean it's always a bit tricky for backends to verify if the fmin/fmax behavior exactly matches the instruction regards signaling nans, rounding etc but if the scalar variant is fine I don't see why the vector variant would be worse. Regards Robin
