Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[StackSlotColoring] Fix issue where colors for a StackID are dropped #138140

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

Jump to bottom
Merged
merged 1 commit into from
May 2, 2025
Merged

[StackSlotColoring] Fix issue where colors for a StackID are dropped #138140

merged 1 commit into from
May 2, 2025

Conversation

MacDue
Copy link
Member

@MacDue MacDue commented May 1, 2025 •
edited
Loading

In InitializeSlots, if an interval with a non-zero StackID (A) is encountered we set All/UsedColors to a size of A + 1. If after this we process another interval with a non-zero StackID (B), where B < A, then we resize All/UsedColors to size < A + 1, and lose the BitVector associated with A.

AFAIK this is a latent bug upstream, but when adding a new TargetStackID locally I hit a NextColors[StackID] != -1 && "No more spill slots?" assertion due to this issue.

@MacDue
[StackSlotColoring] Fix a latent bug
0057c91 
In InitializeSlots, if an interval with a non-zero StackID (A) is
encountered we set All/UsedColors to a size of A + 1. If after this we
process another interval with a non-zero StackID (B), where B < A, then
we resize All/UsedColors to size < A + 1, and loose BitVector
associated with A.
@MacDue MacDue requested review from arsenm and sdesmalen-arm May 1, 2025 14:22
@MacDue
Copy link
Member Author

MacDue commented May 1, 2025

I don't think anyone has hit this upstream, but I encountered this issue after adding a new TargetStackID locally.

arsenm
arsenm reviewed May 1, 2025
View reviewed changes
Copy link
Contributor

@arsenm arsenm left a comment

Choose a reason for hiding this comment

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

Title should be more specific about what bug

@MacDue MacDue changed the title [StackSlotColoring] Fix a latent bug [StackSlotColoring] Fix issue where colors for a StackID are dropped May 1, 2025
sdesmalen-arm
sdesmalen-arm reviewed May 1, 2025
View reviewed changes
Copy link
Collaborator

@sdesmalen-arm sdesmalen-arm left a comment

Choose a reason for hiding this comment

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

Would it be possible to create an MIR test that does a run-pass=stackslot-coloring, using objects with scalable-vector (2) and noalloc (255) stack IDs to expose this case? I don't think this pass cares specifically about the meaning of these stack IDs.

@MacDue
Copy link
Member Author

MacDue commented May 1, 2025

Would it be possible to create an MIR test that does a run-pass=stackslot-coloring, using objects with scalable-vector (2) and noalloc (255) stack IDs to expose this case? I don't think this pass cares specifically about the meaning of these stack IDs.

It does not seem possible right now. The stack-slot-coloring pass uses the LiveStacksAnalysis to find the stack slot live ranges, but that's not a real analysis, it's just a stub, with the actual liveness information filled in by the register allocator.

llvm-project/llvm/lib/CodeGen/LiveStacks.cpp

Lines 48 to 49 in c617466

// FIXME: No analysis is being done right now. We are relying on the
// register allocators to provide the information.

So, to get the stack slot liveness information, the register allocator needs to run and create stack slots. Since the register allocator makes the stack slots, I can't edit them to have the noalloc StackID. If I run the register allocator separately to generate the MIR, there's no stack slot liveness information, so the stack-slot-coloring pass is a nop.

@arsenm
Copy link
Contributor

arsenm commented May 1, 2025

So, to get the stack slot liveness information, the register allocator needs to run and create stack slots. Since the register allocator makes the stack slots, I can't edit them to have the noalloc StackID. If I run the register allocator separately to generate the MIR, there's no stack slot liveness information, so the stack-slot-coloring pass is a nop.

What if you have pre-existing frame indexes, and then run through the allocator?

@MacDue
Copy link
Member Author

MacDue commented May 1, 2025 •
edited
Loading

What if you have pre-existing frame indexes, and then run through the allocator?

I don't think those are included. IIUC it's only the InlineSpiller that updates the LiveStackAnalysis:

llvm-project/llvm/lib/CodeGen/InlineSpiller.cpp

Lines 1260 to 1264 in a7aca81

// Update LiveStacks now that we are committed to spilling.
if (StackSlot == VirtRegMap::NO_STACK_SLOT) {
StackSlot = VRM.assignVirt2StackSlot(Original);
StackInt = &LSS.getOrCreateInterval(StackSlot, MRI.getRegClass(Original));
StackInt->getNextValue(SlotIndex(), LSS.getVNInfoAllocator());
I can't see any reference to getOrCreateInterval anywhere else in the codebase and the InlineSpiller appears to create the stack slots it tracks (in assignVirt2StackSlot() just before).

@MacDue MacDue merged commit 40edb37 into llvm:main May 2, 2025
13 checks passed
@MacDue MacDue deleted the latent_bug branch May 2, 2025 09:23
IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
@MacDue @IanWood1
[StackSlotColoring] Fix issue where colors for a StackID are dropped (l…
ddfd941 
…lvm#138140)

In InitializeSlots, if an interval with a non-zero StackID (A) is
encountered we set All/UsedColors to a size of A + 1. If after this we
process another interval with a non-zero StackID (B), where B < A, then
we resize All/UsedColors to size < A + 1, and lose the BitVector
associated with A.

AFAIK this is a latent bug upstream, but when adding a new TargetStackID
locally I hit a `NextColors[StackID] != -1 && "No more spill slots?"`
assertion due to this issue.
IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
@MacDue @IanWood1
[StackSlotColoring] Fix issue where colors for a StackID are dropped (l…
86c3585 
…lvm#138140)

In InitializeSlots, if an interval with a non-zero StackID (A) is
encountered we set All/UsedColors to a size of A + 1. If after this we
process another interval with a non-zero StackID (B), where B < A, then
we resize All/UsedColors to size < A + 1, and lose the BitVector
associated with A.

AFAIK this is a latent bug upstream, but when adding a new TargetStackID
locally I hit a `NextColors[StackID] != -1 && "No more spill slots?"`
assertion due to this issue.
IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
@MacDue @IanWood1
[StackSlotColoring] Fix issue where colors for a StackID are dropped (l…
fe2d752 
…lvm#138140)

In InitializeSlots, if an interval with a non-zero StackID (A) is
encountered we set All/UsedColors to a size of A + 1. If after this we
process another interval with a non-zero StackID (B), where B < A, then
we resize All/UsedColors to size < A + 1, and lose the BitVector
associated with A.

AFAIK this is a latent bug upstream, but when adding a new TargetStackID
locally I hit a `NextColors[StackID] != -1 && "No more spill slots?"`
assertion due to this issue.
GeorgeARM pushed a commit to GeorgeARM/llvm-project that referenced this pull request May 7, 2025
@MacDue @GeorgeARM
[StackSlotColoring] Fix issue where colors for a StackID are dropped (l…
2fa72cc 
…lvm#138140)

In InitializeSlots, if an interval with a non-zero StackID (A) is
encountered we set All/UsedColors to a size of A + 1. If after this we
process another interval with a non-zero StackID (B), where B < A, then
we resize All/UsedColors to size < A + 1, and lose the BitVector
associated with A.

AFAIK this is a latent bug upstream, but when adding a new TargetStackID
locally I hit a `NextColors[StackID] != -1 && "No more spill slots?"`
assertion due to this issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@arsenm arsenm arsenm approved these changes

@sdesmalen-arm sdesmalen-arm sdesmalen-arm approved these changes

Assignees
No one assigned
Labels
llvm:codegen
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@MacDue @arsenm @sdesmalen-arm