Skip to content

[SandboxIR] Implement missing PHINode functions #101734

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 7 commits into from
Aug 6, 2024

Conversation

Sterling-Augustine
Copy link
Contributor

replaceIncomingBlockWith and removeIncomingValueIf are both straightforward and done.

I'll defer copyIncomingBlocks until a couple of other changes that also handle blocks go in.

replaceIncomingBlockWith and removeIncomingValueIf are both
straightforward and done.

I'll defer copyIncomingBlocks until a couple of other changes that
also handle blocks go in.
Copy link

github-actions bot commented Aug 2, 2024

✅ With the latest revision this PR passed the C/C++ code formatter.

@aeubanks
Copy link
Contributor

aeubanks commented Aug 2, 2024

please prefix the commit title with [SandboxIR]

setIncomingBlock(Op, New);
}
void PHINode::removeIncomingValueIf(function_ref< bool(unsigned)> Predicate,
bool DeletePHIIfEmpty) {
Copy link

Choose a reason for hiding this comment

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

DeletePHIIfEmpty is dead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, should be passed through to the llvmir function.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Blah. It turns out that deleting empty PHINodes is unimplemented in the tracker right now, and needs cleanup in several places. I'll delete this use for now and fix it in a variety of places in a later follow up.

Copy link
Contributor

@vporpo vporpo left a comment

Choose a reason for hiding this comment

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

I think we also need a test in TrackerTest.cpp (in PHINodeSetters test) to make sure that replaceIncomingBlockWith() and removeIncomingValueIf() can be reverted properly. They currently call functions that are being tracked, so tracking should work fine, but this may change, and we don't want tracking to fail silently.

auto *NewBB = BB2;
EXPECT_NE(NewBB, OrigBB);
PHI->replaceIncomingBlockWith(OrigBB, NewBB);
EXPECT_EQ(PHI->getIncomingBlock(0), NewBB);
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's also check that no other incoming block has changed.

return PHI->getIncomingBlock(Idx) == NewBB;
});
EXPECT_EQ(PHI->getNumIncomingValues(), 1u);
EXPECT_EQ(PHI->getIncomingBlock(0), BB3);
// Check create().
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should exercise removeIncomingValueIf() a bit more. In the existing check we are removing the first two values if I am not mistaken: (NewBB, NewBB, BB3) -> (BB3).
Maybe we should try removing the last incoming value, resulting in an empty PHI, and perhaps a different pattern with gaps, like (A, B, C, D) -> (B, D).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

});
EXPECT_EQ(PHI->getNumIncomingValues(), 1u);
Ctx.revert();
EXPECT_EQ(PHI->getNumIncomingValues(), 2u);
Copy link
Contributor

Choose a reason for hiding this comment

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

It's probably best to check the actual incoming values here too, not just there are 2 of them

Update test for much more complicated case.
Copy link
Contributor

@vporpo vporpo left a comment

Choose a reason for hiding this comment

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

LGTM

@Sterling-Augustine Sterling-Augustine merged commit 66f4e3f into llvm:main Aug 6, 2024
4 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants