aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/MachOObjectFile.cpp
diff options
context:
space:
mode:
authorPhilip Reames <preames@rivosinc.com>2022-12-13 12:01:32 -0800
committerPhilip Reames <listmail@philipreames.com>2022-12-13 12:16:26 -0800
commit668cde81df533b5aef0907e72148441bf5e5a383 (patch)
treec78b621f5b72a5d17e9f2c6d43c5fae76b8a4182 /llvm/lib/Object/MachOObjectFile.cpp
parent22702cc76c4d6fcd3ee0e37ca826c539af146494 (diff)
downloadllvm-668cde81df533b5aef0907e72148441bf5e5a383.zip
llvm-668cde81df533b5aef0907e72148441bf5e5a383.tar.gz
llvm-668cde81df533b5aef0907e72148441bf5e5a383.tar.bz2
[RISCV] Reuse VL (if non-zero) when building single element vector for start of reduction chain
This is an alternative patch on a path to D137530. The basic problem being tackled here is that we need to place a scalar into lane 0 of a vector register before our reduction instructions. Since we only care about lane 0 of the vector, we can use any VL >= 1 provided that the total amount of work performed matches the work performed for a VL=1. This change does not contain the logic from D137530 to perform the insert at the original VT, and then extract down to LMUL1. That turns out to be a good choice, as discussion in this review has indicated there are issues around LMUL2 and above with our representation of vmv.s.x. We'd also need to be careful with the splat logic for the same reasons. The only potentially concerning codegen change I spot here is that we stop using a broadcast load (for VL=1) and instead do a scalar load and insert. I think this is probably reasonable; if reviewers disagree, I can investigate using a broadcast load which writes to the undef lanes. If we want to do that, we should do it for VECTOR_INSERT_ELT as well, so that'll end up as it's own patch series. Differential Revision: https://reviews.llvm.org/D139656
Diffstat (limited to 'llvm/lib/Object/MachOObjectFile.cpp')
0 files changed, 0 insertions, 0 deletions