Skip to content

Commit 4710e78

Browse files
committed
[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
1 parent 27aca97 commit 4710e78

File tree

1 file changed

+2
-10
lines changed

1 file changed

+2
-10
lines changed

llvm/lib/Target/RISCV/RISCVTargetTransformInfo.cpp

Lines changed: 2 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -132,16 +132,8 @@ bool RISCVTTIImpl::shouldExpandReduction(const IntrinsicInst *II) const {
132132
}
133133

134134
Optional<unsigned> RISCVTTIImpl::getMaxVScale() const {
135-
// There is no assumption of the maximum vector length in V specification.
136-
// We use the value specified by users as the maximum vector length.
137-
// This function will use the assumed maximum vector length to get the
138-
// maximum vscale for LoopVectorizer.
139-
// If users do not specify the maximum vector length, we have no way to
140-
// know whether the LoopVectorizer is safe to do or not.
141-
// We only consider to use single vector register (LMUL = 1) to vectorize.
142-
unsigned MaxVectorSizeInBits = ST->getMaxRVVVectorSizeInBits();
143-
if (ST->hasVInstructions() && MaxVectorSizeInBits != 0)
144-
return MaxVectorSizeInBits / RISCV::RVVBitsPerBlock;
135+
if (ST->hasVInstructions())
136+
return ST->getRealMaxVLen() / RISCV::RVVBitsPerBlock;
145137
return BaseT::getMaxVScale();
146138
}
147139

0 commit comments

Comments
 (0)