[LLVM] Fix a bug in auto upgrading lifetime start/end intrinsics#204601
Merged
Conversation
When creating the new intrinsic declaration, use the correct pointer argument (arg llvm#1) from the existing call. Currently, we use arg #0 (size) and end up creating an invalid intrinsic declaration. However, later on we do not use this declaration directly and instead call `CreateLifetimeStart` or `CreateLifetimeEnd` IRBuilder functions that end up creating valid intrinsic declarations. The net result is that we are left with a stray unused invalid declaration. Fix this issue by creating the intrinsic with the right pointer argument type.
jurahul
marked this pull request as ready for review
June 18, 2026 14:54
|
@llvm/pr-subscribers-llvm-ir Author: Rahul Joshi (jurahul) ChangesWhen creating the new intrinsic declaration, use the correct pointer argument (arg #1) from the existing call. Currently, we use arg #0 (size) and end up creating an invalid intrinsic declaration. However, later on we do not use this declaration directly and instead call Fix this issue by creating the intrinsic with the right pointer argument type. Full diff: https://github.com/llvm/llvm-project/pull/204601.diff 2 Files Affected:
diff --git a/llvm/lib/IR/AutoUpgrade.cpp b/llvm/lib/IR/AutoUpgrade.cpp
index 814e985ebf7be..4d353c95b8930 100644
--- a/llvm/lib/IR/AutoUpgrade.cpp
+++ b/llvm/lib/IR/AutoUpgrade.cpp
@@ -1556,8 +1556,10 @@ static bool upgradeIntrinsicFunction1(Function *F, Function *&NewFn,
? Intrinsic::lifetime_start
: Intrinsic::lifetime_end;
rename(F);
+ // Old 2 argument form of these intrinsics have [Size, Ptr] as arguments.
+ // Use the Ptr argument to create new declaration.
NewFn = Intrinsic::getOrInsertDeclaration(F->getParent(), IID,
- F->getArg(0)->getType());
+ F->getArg(1)->getType());
return true;
}
break;
diff --git a/llvm/test/Assembler/autoupgrade-lifetime-intrinsics-invalid-decl.ll b/llvm/test/Assembler/autoupgrade-lifetime-intrinsics-invalid-decl.ll
new file mode 100644
index 0000000000000..dec73f40bb451
--- /dev/null
+++ b/llvm/test/Assembler/autoupgrade-lifetime-intrinsics-invalid-decl.ll
@@ -0,0 +1,17 @@
+; Test to verify that autoupgrade does not end up creating an invalid
+; declaration.
+; RUN: llvm-as < %s | llvm-dis | FileCheck %s
+
+; CHECK-NOT: declare void @llvm.lifetime.start.i64(i64)
+; CHECK-NOT: declare void @llvm.lifetime.end.i64(i64)
+
+define void @tests.lifetime.start.end() {
+ %a = alloca i8
+ call void @llvm.lifetime.start(i64 1, ptr %a)
+ store i8 0, ptr %a
+ call void @llvm.lifetime.end(i64 1, ptr %a)
+ ret void
+}
+
+declare void @llvm.lifetime.start.p0(i64, ptr)
+declare void @llvm.lifetime.end.p0(i64, ptr)
|
This was referenced Jun 30, 2026
jurahul
added a commit
to jurahul/llvm-project
that referenced
this pull request
Jun 30, 2026
LLVM's AutoUpgrade used to create invalid and unused `lifetime.start.i64` and `lifetime.end.i64` intrinsics. This was fixed with llvm#204601. However, existing bitcode generated prior to this fix might still have these unused and invalid declarations in them. Adopt Autoupgrade to handle them. Invalid declaration of these intrinsics will be deleted, and if there exists calls to these invalid intrinsics (not expected to be generated by AutoUpgrade prior to the bug fix, but handling this case just for completeness) these calls will be deleted.
jurahul
added a commit
to jurahul/llvm-project
that referenced
this pull request
Jun 30, 2026
LLVM's AutoUpgrade used to create invalid and unused `lifetime.start.i64` and `lifetime.end.i64` intrinsics. This was fixed with llvm#204601. However, existing bitcode generated prior to this fix might still have these unused and invalid declarations in them. Adopt Autoupgrade to handle them. Invalid declaration of these intrinsics will be deleted, and if there exists calls to these invalid intrinsics (not expected to be generated by AutoUpgrade prior to the bug fix, but handling this case just for completeness) these calls will be deleted.
jurahul
added a commit
that referenced
this pull request
Jun 30, 2026
…sic decls and calls (#206769) AutoUpgrade used to create invalid and unused `lifetime.start.i64` and `lifetime.end.i64` intrinsics. This was fixed with #204601. However, existing bitcode generated prior to this fix might still have these unused and invalid declarations in them, which now fail IR verification. Adopt Autoupgrade to clean them up. Invalid declaration of these intrinsics will be deleted, and if there exists calls to these invalid intrinsics (not expected to be generated by AutoUpgrade prior to the bug fix, but handling this case just for completeness) these calls will be deleted as well. Also tested with `sap_fct_splitting.bc` reported in #204478 (comment) (though not committing that as a unit test).
llvm-upstreamsync Bot
pushed a commit
to qualcomm/cpullvm-toolchain
that referenced
this pull request
Jun 30, 2026
….end intrinsic decls and calls (#206769) AutoUpgrade used to create invalid and unused `lifetime.start.i64` and `lifetime.end.i64` intrinsics. This was fixed with llvm/llvm-project#204601. However, existing bitcode generated prior to this fix might still have these unused and invalid declarations in them, which now fail IR verification. Adopt Autoupgrade to clean them up. Invalid declaration of these intrinsics will be deleted, and if there exists calls to these invalid intrinsics (not expected to be generated by AutoUpgrade prior to the bug fix, but handling this case just for completeness) these calls will be deleted as well. Also tested with `sap_fct_splitting.bc` reported in llvm/llvm-project#204478 (comment) (though not committing that as a unit test).
llvm-sync Bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Jun 30, 2026
….end intrinsic decls and calls (#206769) AutoUpgrade used to create invalid and unused `lifetime.start.i64` and `lifetime.end.i64` intrinsics. This was fixed with llvm/llvm-project#204601. However, existing bitcode generated prior to this fix might still have these unused and invalid declarations in them, which now fail IR verification. Adopt Autoupgrade to clean them up. Invalid declaration of these intrinsics will be deleted, and if there exists calls to these invalid intrinsics (not expected to be generated by AutoUpgrade prior to the bug fix, but handling this case just for completeness) these calls will be deleted as well. Also tested with `sap_fct_splitting.bc` reported in llvm/llvm-project#204478 (comment) (though not committing that as a unit test).
llvm-upstream-sync Bot
pushed a commit
to sriyalamar/cpullvm-toolchain
that referenced
this pull request
Jun 30, 2026
….end intrinsic decls and calls (#206769) AutoUpgrade used to create invalid and unused `lifetime.start.i64` and `lifetime.end.i64` intrinsics. This was fixed with llvm/llvm-project#204601. However, existing bitcode generated prior to this fix might still have these unused and invalid declarations in them, which now fail IR verification. Adopt Autoupgrade to clean them up. Invalid declaration of these intrinsics will be deleted, and if there exists calls to these invalid intrinsics (not expected to be generated by AutoUpgrade prior to the bug fix, but handling this case just for completeness) these calls will be deleted as well. Also tested with `sap_fct_splitting.bc` reported in llvm/llvm-project#204478 (comment) (though not committing that as a unit test).
maarcosrmz
pushed a commit
to maarcosrmz/llvm-project
that referenced
this pull request
Jul 1, 2026
…sic decls and calls (llvm#206769) AutoUpgrade used to create invalid and unused `lifetime.start.i64` and `lifetime.end.i64` intrinsics. This was fixed with llvm#204601. However, existing bitcode generated prior to this fix might still have these unused and invalid declarations in them, which now fail IR verification. Adopt Autoupgrade to clean them up. Invalid declaration of these intrinsics will be deleted, and if there exists calls to these invalid intrinsics (not expected to be generated by AutoUpgrade prior to the bug fix, but handling this case just for completeness) these calls will be deleted as well. Also tested with `sap_fct_splitting.bc` reported in llvm#204478 (comment) (though not committing that as a unit test).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When creating the new intrinsic declaration, use the correct pointer argument (arg #1) from the existing call. Currently, we use arg #0 (size) and end up creating an invalid intrinsic declaration. However, later on we do not use this declaration directly and instead call
CreateLifetimeStartorCreateLifetimeEndIRBuilder functions that end up creating valid intrinsic declarations. The net result is that we are left with a stray unused invalid declaration.Fix this issue by creating the intrinsic with the right pointer argument type.