diff options
| author | Philip Reames <preames@rivosinc.com> | 2022-06-24 16:48:21 -0700 |
|---|---|---|
| committer | Philip Reames <listmail@philipreames.com> | 2022-06-24 16:51:53 -0700 |
| commit | 4710e789741fd69a0044f96138e7e874a4e1f74d (patch) | |
| tree | 781d41f5ac5294bc588c6439b1c7f92f5555c807 /llvm/tools/llvm-objdump/llvm-objdump.cpp | |
| parent | 27aca975b6b6e9d5c7516c091f954884b28650ae (diff) | |
| download | llvm-4710e789741fd69a0044f96138e7e874a4e1f74d.zip llvm-4710e789741fd69a0044f96138e7e874a4e1f74d.tar.gz llvm-4710e789741fd69a0044f96138e7e874a4e1f74d.tar.bz2 | |
[RISCV] Implement RISCVTTIImpl::getMaxVScale correctly
The comments in the existing code appear to pre-exist the standardization of the +v extension. In particular, the specification *does* provide a bound on the maximum value VLEN can take. From what I can tell, the LMUL comment was simply a misunderstanding of what this API returns.
This API returns the maximum value that vscale can take at runtime. This is used in the vectorizer to bound the largest scalable VF (e.g. LMUL in RISCV terms) which can be used without violating memory dependence.
Differential Revision: https://reviews.llvm.org/D128538
Diffstat (limited to 'llvm/tools/llvm-objdump/llvm-objdump.cpp')
0 files changed, 0 insertions, 0 deletions