Skip to content

[ValueTracking] Fix KnownBits conflict for calls (range vs returned) #84353

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.

Sign up for GitHub

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
Mar 7, 2024
+20 −0
Merged

[ValueTracking] Fix KnownBits conflict for calls (range vs returned) #84353

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions llvm/lib/Analysis/ValueTracking.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1476,6 +1476,12 @@ static void computeKnownBitsFromOperator(const Operator *I,
if (RV->getType() == I->getType()) {
computeKnownBits(RV, Known2, Depth + 1, Q);
Known = Known.unionWith(Known2);
Copy link
Contributor

Choose a reason for hiding this comment

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

should this not be just intersectWith?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I was a bit confused as well given that the code comments talks about intersect, and then the code is doing union.
But I figured that generally we could have that the range matadata says that the function returns values in the range [0, 15] while the returned arg is known to be 8. Given that we use unionWith we would derive that the call will return 8. If we use intersectWith, then we would only get the common knowledge of bits that are zero/one. So the know bits would indicate that the returned value is in the range [0, 15].

Copy link
Contributor

Choose a reason for hiding this comment

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

The naming of the methods is a bit confusing. This is a union in the sense that we take all the available information from both operands. Not in the sense that we union two ranges.

// If the function doesn't return properly for all input values
// (e.g. unreachable exits) then there might be conflicts between the
// argument value and the range metadata. Simply discard the known bits
// in case of conflicts.
if (Known.hasConflict())
Known.resetAll();
}
}
if (const IntrinsicInst *II = dyn_cast<IntrinsicInst>(I)) {
Expand Down
14 changes: 14 additions & 0 deletions llvm/unittests/Analysis/ValueTrackingTest.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2359,6 +2359,20 @@ TEST_F(ComputeKnownBitsTest, ComputeKnownBitsFreeze) {
EXPECT_EQ(Known.One.getZExtValue(), 0u);
}

TEST_F(ComputeKnownBitsTest, ComputeKnownBitsReturnedRangeConflict) {
parseAssembly(
"declare i16 @foo(i16 returned)\n"
"\n"
"define i16 @test() {\n"
" %A = call i16 @foo(i16 4095), !range !{i16 32, i16 33}\n"
" ret i16 %A\n"
"}\n");
// The call returns 32 according to range metadata, but 4095 according to the
// returned arg operand. Given the conflicting information we expect that the
// known bits information simply is cleared.
expectKnownBits(/*zero*/ 0u, /*one*/ 0u);
}

TEST_F(ComputeKnownBitsTest, ComputeKnownBitsAddWithRange) {
parseAssembly("define void @test(ptr %p) {\n"
" %A = load i64, ptr %p, !range !{i64 64, i64 65536}\n"
Expand Down