[SOL] Use a relative bump for stack in sBPFv3 #181
Conversation
LucasSte
changed the title
|
This leaves a lot of usable stack space on the table. I think it would be better to always subtract |
We always allocate the same amount of stack for all programs, right? I did not take that approach because that would increase CU consumption, and people complain about that constantly. We could add the option for "stack management optimization" (which follows your suggestion) behind a feature flag. How does that sound? |
LucasSte
merged commit aa4803f
into
anza-xyz:solana-rustc/20.1-2025-02-13
Upstream commits merged (already applied with TBF/TOS adaptations): - aa4803f [SOL] Use a relative bump for stack in sBPFv3 (anza-xyz#181) - 427d50d [SOL] Emit EM_BPF for SBPFv3 (anza-xyz#180) These changes were previously cherry-picked and adapted for TBF/TOS naming in commits f3c4c39, 77dcae2, 7864f44, and 209ddfa. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
2 participants
In sBPFv3, we are giving 4096 bytes of stack for free, and only bumping the frame pointer if the function requires more than that.
This PR adjusts the SBF backend to do exactly that.