AArch64: fix bitcode upgrade of @llvm.neon.addp.
authorTim Northover <t.p.northover@gmail.com>
Thu, 9 Jan 2020 14:28:48 +0000 (14:28 +0000)
committerTim Northover <t.p.northover@gmail.com>
Tue, 14 Jan 2020 13:41:32 +0000 (13:41 +0000)
We were upgrading it to faddp, but a version taking two type parameters instead
of one. This then got upgraded a second time to the version with just one
parameter, but occasionally (for reasons I don't understand) this unusual
two-stage process corrupted a use-list, leading to a crash when the two faddp
declarations didn't match.

llvm/lib/IR/AutoUpgrade.cpp
llvm/test/Bitcode/aarch64-addp-upgrade.bc [new file with mode: 0644]
llvm/test/Bitcode/aarch64-addp-upgrade.ll [new file with mode: 0644]

index ecd1a12..6e2beeb 100644 (file)
@@ -585,11 +585,10 @@ static bool UpgradeIntrinsicFunction1(Function *F, Function *&NewFn) {
     if (Name.startswith("aarch64.neon.addp")) {
       if (F->arg_size() != 2)
         break; // Invalid IR.
-      auto fArgs = F->getFunctionType()->params();
-      VectorType *ArgTy = dyn_cast<VectorType>(fArgs[0]);
-      if (ArgTy && ArgTy->getElementType()->isFloatingPointTy()) {
+      VectorType *Ty = dyn_cast<VectorType>(F->getReturnType());
+      if (Ty && Ty->getElementType()->isFloatingPointTy()) {
         NewFn = Intrinsic::getDeclaration(F->getParent(),
-                                          Intrinsic::aarch64_neon_faddp, fArgs);
+                                          Intrinsic::aarch64_neon_faddp, Ty);
         return true;
       }
     }
diff --git a/llvm/test/Bitcode/aarch64-addp-upgrade.bc b/llvm/test/Bitcode/aarch64-addp-upgrade.bc
new file mode 100644 (file)
index 0000000..a359b44
Binary files /dev/null and b/llvm/test/Bitcode/aarch64-addp-upgrade.bc differ
diff --git a/llvm/test/Bitcode/aarch64-addp-upgrade.ll b/llvm/test/Bitcode/aarch64-addp-upgrade.ll
new file mode 100644 (file)
index 0000000..4e78996
--- /dev/null
@@ -0,0 +1,18 @@
+; RUN: llvm-dis %p/aarch64-addp-upgrade.bc -o - | FileCheck %s
+
+; Bitcode was generated from file below, which may or may not even assemble any
+; more.
+
+; CHECK: call <2 x float> @llvm.aarch64.neon.faddp.v2f32(<2 x float> %lhs, <2 x float> %rhs)
+define <2 x float> @test_addp(<2 x float> %lhs, <2 x float> %rhs) {
+  %res = call <2 x float> @llvm.aarch64.neon.addp.v2f32(<2 x float> %lhs, <2 x float> %rhs)
+  ret <2 x float> %res
+}
+
+; CHECK: call <2 x float> @llvm.aarch64.neon.faddp.v2f32(<2 x float> %lhs, <2 x float> %rhs)
+define <2 x float> @test_addp1(<2 x float> %lhs, <2 x float> %rhs) {
+  %res = call <2 x float> @llvm.aarch64.neon.addp.v2f32(<2 x float> %lhs, <2 x float> %rhs)
+  ret <2 x float> %res
+}
+
+declare <2 x float> @llvm.aarch64.neon.addp.v2f32(<2 x float>, <2 x float>)