Skip to content

[ARM64] [Windows] Mark block address as taken when expanding catchrets #109252

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 1 commit into from
Sep 30, 2024

Conversation

momo5502
Copy link
Contributor

This fixes issue #109250

The issue happens during the MachineBlockPlacement pass. The block, whose address was previously not taken, is deemed redundant by the pass and subsequently replaced using
MachineBasicBlock::ReplaceUsesOfBlockWith in BranchFolding.

ReplaceUsesOfBlockWith only replaces uses in the terminator. However, expandPostRAPseudo introduces new block uses when expanding catchrets. These uses do not get replaced, which results in undefined label errors later on.

Marking the block addresss as taken prevents the replacement of the block, without also replacing non-terminator uses.

@llvmbot
Copy link
Member

llvmbot commented Sep 19, 2024

@llvm/pr-subscribers-backend-aarch64

Author: Maurice Heumann (momo5502)

Changes

This fixes issue #109250

The issue happens during the MachineBlockPlacement pass. The block, whose address was previously not taken, is deemed redundant by the pass and subsequently replaced using
MachineBasicBlock::ReplaceUsesOfBlockWith in BranchFolding.

ReplaceUsesOfBlockWith only replaces uses in the terminator. However, expandPostRAPseudo introduces new block uses when expanding catchrets. These uses do not get replaced, which results in undefined label errors later on.

Marking the block addresss as taken prevents the replacement of the block, without also replacing non-terminator uses.


Full diff: https://github.com/llvm/llvm-project/pull/109252.diff

1 Files Affected:

  • (modified) llvm/lib/Target/AArch64/AArch64InstrInfo.cpp (+1)
diff --git a/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp b/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
index 3b38a5f78dee51..32bc0e7d0d6475 100644
--- a/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
+++ b/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
@@ -1994,6 +1994,7 @@ bool AArch64InstrInfo::expandPostRAPseudo(MachineInstr &MI) const {
         .addReg(AArch64::X0)
         .addMBB(TargetMBB)
         .addImm(0);
+    TargetMBB->setMachineBlockAddressTaken();
     return true;
   }
 

@efriedma-quic
Copy link
Collaborator

Code change makes sense; please add a testcase.

@momo5502
Copy link
Contributor Author

Code change makes sense; please add a testcase.

I added the sample from the issue as a test case to assert the issue does not occur anymore. I hope this is fine.
Asserting that the block address is taken should by covered by adjusting the two existing tests.

@momo5502
Copy link
Contributor Author

Is the test fine like this?

This fixes issue llvm#109250

The issue happens during the `MachineBlockPlacement` pass.
The block, whose address was previously not taken, is deemed redundant
by the pass and subsequently replaced using
`MachineBasicBlock::ReplaceUsesOfBlockWith` in `BranchFolding`.

ReplaceUsesOfBlockWith only replaces uses in the terminator.
However, `expandPostRAPseudo` introduces new block uses
when expanding catchrets. These uses do not get replaced, which results
in undefined label errors later on.

Marking the block addresss as taken prevents the replacement of the block,
without also replacing non-terminator uses.
Copy link
Collaborator

@efriedma-quic efriedma-quic left a comment

Choose a reason for hiding this comment

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

LGTM

@momo5502
Copy link
Contributor Author

LGTM

Thanks, would you mind merging it for me, please?

@efriedma-quic efriedma-quic merged commit 607c525 into llvm:main Sep 30, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants