Previously when llvm.reduce.* lowered, riscv backend created scalar vector with
netural element as start value. For llvm.reduce.and/or/min/max/fmax/fmin, we
could use the first element of source as the start value. It's benefit for RVV
since we could just use source vector as start vector.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
I can't speak for the fmin/fmax parts, but for the integer ops this makes sense to me
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
7661–7662 | What happens it it's not converted to a scalable vector? |
Comment Actions
This update does 3 things:
- Since (extractelement fixed_vec, 0) may be a start of vp.reduce, we need to handle this for lowerScalarInsert.
- Remove function getFirstElement().
- Add test CodeGen/RISCV/rvv/combine-extractelement-vp-reduce.ll for 1.
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
3475 | Is VT here always scalable? |
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
3475 | I think all lowerScalarInsert calls use scalable vector VT and it looks like lowerScalarInsert can't have fixed vector VT. |
llvm/lib/Target/RISCV/RISCVISelLowering.cpp | ||
---|---|---|
3475 | can you add an assertion? |
It just that fixed vectors are hard to compares with scalable vector type here.