Skip to content

[RISCV] Disable fixed vectors in getOptimalMemOpType if minimum VLEN is 32. #102974

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 13, 2024

Conversation

topperc
Copy link
Collaborator

@topperc topperc commented Aug 12, 2024

This is needed to match #102405 which disabled fixed to scalable vector lowering for VLEN=32.

Fixes #102566 and #102568.

…is 32.

This is needed to match llvm#102405 which disabled fixed to scalable
vector lowering for VLEN=32.

Fixes llvm#102566 and 102568.
@llvmbot
Copy link
Member

llvmbot commented Aug 12, 2024

@llvm/pr-subscribers-backend-risc-v

Author: Craig Topper (topperc)

Changes

This is needed to match #102405 which disabled fixed to scalable vector lowering for VLEN=32.

Fixes #102566 and #102568.


Full diff: https://github.com/llvm/llvm-project/pull/102974.diff

2 Files Affected:

  • (modified) llvm/lib/Target/RISCV/RISCVISelLowering.cpp (+5)
  • (added) llvm/test/CodeGen/RISCV/rvv/memcpy-crash-zvl32b.ll (+17)
diff --git a/llvm/lib/Target/RISCV/RISCVISelLowering.cpp b/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
index 3beaa5198259d0..6fde09d89e4839 100644
--- a/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
+++ b/llvm/lib/Target/RISCV/RISCVISelLowering.cpp
@@ -21024,6 +21024,11 @@ EVT RISCVTargetLowering::getOptimalMemOpType(const MemOp &Op,
     // which ends up using scalar sequences.
     return MVT::Other;
 
+  // If the minimum VLEN is less than RISCV::RVVBitsPerBlock we don't support
+  // fixed vectors.
+  if (MinVLenInBytes <= RISCV::RVVBitsPerBlock / 8)
+    return MVT::Other;
+
   // Prefer i8 for non-zero memset as it allows us to avoid materializing
   // a large scalar constant and instead use vmv.v.x/i to do the
   // broadcast.  For everything else, prefer ELenVT to minimize VL and thus
diff --git a/llvm/test/CodeGen/RISCV/rvv/memcpy-crash-zvl32b.ll b/llvm/test/CodeGen/RISCV/rvv/memcpy-crash-zvl32b.ll
new file mode 100644
index 00000000000000..e020fe1a0aa1ac
--- /dev/null
+++ b/llvm/test/CodeGen/RISCV/rvv/memcpy-crash-zvl32b.ll
@@ -0,0 +1,17 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 5
+; RUN: llc < %s -mtriple=riscv64 -mattr=+zve32x | FileCheck %s
+
+; Make sure we don't with VLEN=32.
+
+define void @c() {
+; CHECK-LABEL: c:
+; CHECK:       # %bb.0: # %entry
+; CHECK-NEXT:    lw a0, 0(zero)
+; CHECK-NEXT:    sw a0, 0(zero)
+; CHECK-NEXT:    ret
+entry:
+  call void @llvm.memcpy.p0.p0.i64(ptr null, ptr null, i64 4, i1 false)
+  ret void
+}
+
+declare void @llvm.memcpy.p0.p0.i64(ptr noalias nocapture writeonly, ptr noalias nocapture readonly, i64, i1 immarg) #1

Copy link
Collaborator

@preames preames left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@topperc topperc merged commit c772f5d into llvm:main Aug 13, 2024
8 of 10 checks passed
@topperc topperc deleted the pr/memoptype branch August 13, 2024 03:55
@fanghuaqi
Copy link

These PRs #102405 and #102974 will affect the release 19.1.0, maybe can be backport to that release.

@preames
Copy link
Collaborator

preames commented Sep 27, 2024

These PRs #102405 and #102974 will affect the release 19.1.0, maybe can be backport to that release.

I have no particular objection to this being backported, but I do want to clearly note that a minimum VLEN of 32 (i.e. zve32x,vze32f) is not a supported configuration. There are probably other problems lurking around this area, and I don't want to give anyone the expectation that this is generally expected to work. At the moment, trying to use zve32x/zve32f is living very dangerously.

@topperc
Copy link
Collaborator Author

topperc commented Sep 27, 2024

At the moment, trying to use zve32x/zve32f is living very dangerously.

zve32x/zve32f are supposed to work as long as zvl64b or higher is also used.

@preames
Copy link
Collaborator

preames commented Sep 27, 2024

At the moment, trying to use zve32x/zve32f is living very dangerously.

zve32x/zve32f are supposed to work as long as zvl64b or higher is also used.

Correct, sorry I should have been more clear about the dangerous configuration. This review is specifically about the zvl32b case.

@fanghuaqi
Copy link

At the moment, trying to use zve32x/zve32f is living very dangerously.

zve32x/zve32f are supposed to work as long as zvl64b or higher is also used.

Yes, I tested with my case, when I pass _zve32f it will not generate any vector instruction, and I want to ask how can I disable the auto vectorization for RVV since most of my cases are written by using rvv intrinsic API.

@topperc
Copy link
Collaborator Author

topperc commented Sep 29, 2024

At the moment, trying to use zve32x/zve32f is living very dangerously.

zve32x/zve32f are supposed to work as long as zvl64b or higher is also used.

Yes, I tested with my case, when I pass _zve32f it will not generate any vector instruction, and I want to ask how can I disable the auto vectorization for RVV since most of my cases are written by using rvv intrinsic API.

-fno-vectorize
-fno-slp-vectorize

@fanghuaqi
Copy link

Yes, I tested with my case, when I pass _zve32f it will not generate any vector instruction, and I want to ask how can I disable the auto vectorization for RVV since most of my cases are written by using rvv intrinsic API.

-fno-vectorize -fno-slp-vectorize

Thanks

fanghuaqi pushed a commit to riscv-mcu/llvm-project that referenced this pull request Jan 16, 2025
…is 32. (llvm#102974)

This is needed to match llvm#102405 which disabled fixed to scalable vector
lowering for VLEN=32.

Fixes llvm#102566 and llvm#102568.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[RISC-V] Assertion `MemVT.getScalarType().bitsLT(VT.getScalarType()) && "Should only be an extending load, not truncating!"' failed.
4 participants