aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support/Unix/Program.inc
diff options
context:
space:
mode:
authorPhilip Reames <preames@rivosinc.com>2022-12-14 07:27:53 -0800
committerPhilip Reames <listmail@philipreames.com>2022-12-14 10:53:34 -0800
commitd86011984e2776835451ff3cad1e80950d7afb9b (patch)
tree3053a9a4449d03a7c925d72d18562987129021b7 /llvm/lib/Support/Unix/Program.inc
parent7b684119abc7d94bad47ec0b97b35598fac412d3 (diff)
downloadllvm-d86011984e2776835451ff3cad1e80950d7afb9b.zip
llvm-d86011984e2776835451ff3cad1e80950d7afb9b.tar.gz
llvm-d86011984e2776835451ff3cad1e80950d7afb9b.tar.bz2
[RISCV] Avoid generate large LMUL vmv.s.x or fvmv.s.f
This is a follow up to patch discussion on D139656. As noted there, M2/M4/M8 versions of these instructions don't actually exist, and using them results in overly constrained register allocation. In that review, we'd talked about moving towards a variant of the instructions which ignored LMUL. I decided to see what happened if we just stopped generating the high LMUL variants, and the results are surprisingly neutral. I only see one minor thing which looks like a real regression among all the churn. I think this is worth doing now to loosen register allocation constraints, and avoid digging our hole around these instructions deeper while thinking about the right model change. Differential Revision: https://reviews.llvm.org/D140027
Diffstat (limited to 'llvm/lib/Support/Unix/Program.inc')
0 files changed, 0 insertions, 0 deletions