[gentoo-commits] repo/gentoo:master commit in: dev-lang/rust/, dev-lang/rust/files/

["Georgy Yakovlev" <gyakovlev@gentoo.org>]

commit:     3b7815004b8f2952c642c81bbfb37cd7945e6cc3
Author:     Georgy Yakovlev <gyakovlev <AT> gentoo <DOT> org>
AuthorDate: Wed May 25 20:08:49 2022 +0000
Commit:     Georgy Yakovlev <gyakovlev <AT> gentoo <DOT> org>
CommitDate: Wed May 25 21:09:32 2022 +0000
URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3b781500

dev-lang/rust: add llvm patches to 1.61.0 to fix SIGFPE

Bug: https://bugs.gentoo.org/847421
Signed-off-by: Georgy Yakovlev <gyakovlev <AT> gentoo.org>

 .../rust/files/1.61.0-llvm_addrspacecast.patch     | 52 +++++++++++++++++
 .../files/1.61.0-llvm_selectInterleaveCount.patch  | 66 ++++++++++++++++++++++
 .../{rust-1.61.0.ebuild => rust-1.61.0-r1.ebuild}  |  2 +
 3 files changed, 120 insertions(+)

diff --git a/dev-lang/rust/files/1.61.0-llvm_addrspacecast.patch b/dev-lang/rust/files/1.61.0-llvm_addrspacecast.patch
new file mode 100644
index 000000000000..9f2ca6ff667b
--- /dev/null
+++ b/dev-lang/rust/files/1.61.0-llvm_addrspacecast.patch
@@ -0,0 +1,52 @@
+From 67a290460c374d5e0d18a06c798896cac0b19e59 Mon Sep 17 00:00:00 2001
+From: Fraser Cormack <fraser@codeplay.com>
+Date: Wed, 16 Mar 2022 10:14:07 +0000
+Subject: [PATCH] [VectorCombine] Insert addrspacecast when crossing address
+ space boundaries
+
+We can not bitcast pointers across different address spaces. This was
+previously fixed in D89577 but then in D93229 an enhancement was added
+which peeks further through the ponter operand, opening up the
+possibility that address-space violations could be introduced.
+
+Instead of bailing as the previous fix did, simply insert an
+addrspacecast cast instruction.
+
+Reviewed By: lebedev.ri
+
+Differential Revision: https://reviews.llvm.org/D121787
+
+(cherry picked from commit 2e44b7872bc638ed884ae4aa86e38b3b47e0b65a)
+---
+ llvm/lib/Transforms/Vectorize/VectorCombine.cpp |  8 ++------
+ .../AMDGPU/as-transition-inseltpoison.ll        |  4 +---
+ .../VectorCombine/AMDGPU/as-transition.ll       |  4 +---
+ .../VectorCombine/X86/load-inseltpoison.ll      | 17 +++++++++++++++++
+ 4 files changed, 21 insertions(+), 12 deletions(-)
+
+diff --git a/llvm/lib/Transforms/Vectorize/VectorCombine.cpp b/llvm/lib/Transforms/Vectorize/VectorCombine.cpp
+index 620d388199e0..258f6c67e54d 100644
+--- a/src/llvm-project/llvm/lib/Transforms/Vectorize/VectorCombine.cpp
++++ b/src/llvm-project/llvm/lib/Transforms/Vectorize/VectorCombine.cpp
+@@ -152,12 +152,7 @@ bool VectorCombine::vectorizeLoadInsert(Instruction &I) {
+   Value *SrcPtr = Load->getPointerOperand()->stripPointerCasts();
+   assert(isa<PointerType>(SrcPtr->getType()) && "Expected a pointer type");
+ 
+-  // If original AS != Load's AS, we can't bitcast the original pointer and have
+-  // to use Load's operand instead. Ideally we would want to strip pointer casts
+-  // without changing AS, but there's no API to do that ATM.
+   unsigned AS = Load->getPointerAddressSpace();
+-  if (AS != SrcPtr->getType()->getPointerAddressSpace())
+-    SrcPtr = Load->getPointerOperand();
+ 
+   // We are potentially transforming byte-sized (8-bit) memory accesses, so make
+   // sure we have all of our type-based constraints in place for this target.
+@@ -245,7 +240,8 @@ bool VectorCombine::vectorizeLoadInsert(Instruction &I) {
+   // It is safe and potentially profitable to load a vector directly:
+   // inselt undef, load Scalar, 0 --> load VecPtr
+   IRBuilder<> Builder(Load);
+-  Value *CastedPtr = Builder.CreateBitCast(SrcPtr, MinVecTy->getPointerTo(AS));
++  Value *CastedPtr = Builder.CreatePointerBitCastOrAddrSpaceCast(
++      SrcPtr, MinVecTy->getPointerTo(AS));
+   Value *VecLd = Builder.CreateAlignedLoad(MinVecTy, CastedPtr, Alignment);
+   VecLd = Builder.CreateShuffleVector(VecLd, Mask);

diff --git a/dev-lang/rust/files/1.61.0-llvm_selectInterleaveCount.patch b/dev-lang/rust/files/1.61.0-llvm_selectInterleaveCount.patch
new file mode 100644
index 000000000000..71a4e8df75d8
--- /dev/null
+++ b/dev-lang/rust/files/1.61.0-llvm_selectInterleaveCount.patch
@@ -0,0 +1,66 @@
+From fe8a27acd716a42667f5a572f52f2b04636010ff Mon Sep 17 00:00:00 2001
+From: Florian Hahn <flo@fhahn.com>
+Date: Tue, 29 Mar 2022 22:52:42 +0100
+Subject: [PATCH] [LV] Handle zero cost loops in selectInterleaveCount.
+
+In some case, like in the added test case, we can reach
+selectInterleaveCount with loops that actually have a cost of 0.
+
+Unfortunately a loop cost of 0 is also used to communicate that the cost
+has not been computed yet. To resolve the crash, bail out if the cost
+remains zero after computing it.
+
+This seems like the best option, as there are multiple code paths that
+return a cost of 0 to force a computation in selectInterleaveCount.
+Computing the cost at multiple places up front there would unnecessarily
+complicate the logic.
+
+Fixes #54413.
+
+(cherry picked from commit ecb4171dcbf1b433c9963fd605a74898303e850d)
+---
+ .../Transforms/Vectorize/LoopVectorize.cpp    | 22 ++++----
+ ...ct-interleave-count-loop-with-cost-zero.ll | 50 +++++++++++++++++++
+ 2 files changed, 62 insertions(+), 10 deletions(-)
+ create mode 100644 llvm/test/Transforms/LoopVectorize/X86/pr54413-select-interleave-count-loop-with-cost-zero.ll
+
+diff --git a/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp b/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
+index 21c16f07e237..e1cc7946073e 100644
+--- a/src/llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
++++ b/src/llvm-project/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
+@@ -6035,6 +6035,18 @@ unsigned LoopVectorizationCostModel::selectInterleaveCount(ElementCount VF,
+       !(InterleaveSmallLoopScalarReduction && HasReductions && VF.isScalar()))
+     return 1;
+ 
++  // If we did not calculate the cost for VF (because the user selected the VF)
++  // then we calculate the cost of VF here.
++  if (LoopCost == 0) {
++    InstructionCost C = expectedCost(VF).first;
++    assert(C.isValid() && "Expected to have chosen a VF with valid cost");
++    LoopCost = *C.getValue();
++
++    // Loop body is free and there is no need for interleaving.
++    if (LoopCost == 0)
++      return 1;
++  }
++
+   RegisterUsage R = calculateRegisterUsage({VF})[0];
+   // We divide by these constants so assume that we have at least one
+   // instruction that uses at least one register.
+@@ -6126,16 +6138,6 @@ unsigned LoopVectorizationCostModel::selectInterleaveCount(ElementCount VF,
+ 
+   assert(IC > 0 && "Interleave count must be greater than 0.");
+ 
+-  // If we did not calculate the cost for VF (because the user selected the VF)
+-  // then we calculate the cost of VF here.
+-  if (LoopCost == 0) {
+-    InstructionCost C = expectedCost(VF).first;
+-    assert(C.isValid() && "Expected to have chosen a VF with valid cost");
+-    LoopCost = *C.getValue();
+-  }
+-
+-  assert(LoopCost && "Non-zero loop cost expected");
+-
+   // Interleave if we vectorized this loop and there is a reduction that could
+   // benefit from interleaving.
+   if (VF.isVector() && HasReductions) {

diff --git a/dev-lang/rust/rust-1.61.0.ebuild b/dev-lang/rust/rust-1.61.0-r1.ebuild
similarity index 99%
rename from dev-lang/rust/rust-1.61.0.ebuild
rename to dev-lang/rust/rust-1.61.0-r1.ebuild
index e503b90edf91..f8852b27e97e 100644
--- a/dev-lang/rust/rust-1.61.0.ebuild
+++ b/dev-lang/rust/rust-1.61.0-r1.ebuild
@@ -156,6 +156,8 @@ VERIFY_SIG_OPENPGP_KEY_PATH=${BROOT}/usr/share/openpgp-keys/rust.asc
 PATCHES=(
 	"${FILESDIR}"/1.55.0-ignore-broken-and-non-applicable-tests.patch
 	"${FILESDIR}"/1.61.0-gentoo-musl-target-specs.patch
+	"${FILESDIR}"/1.61.0-llvm_selectInterleaveCount.patch
+	"${FILESDIR}"/1.61.0-llvm_addrspacecast.patch
 )
 
 S="${WORKDIR}/${MY_P}-src"