c-variadic: use emit_ptr_va_arg for va_arg on sparc - #160660
Open
folkertdev wants to merge 1 commit into
Open
Conversation
folkertdev
force-pushed
the
sparc-va-arg
branch
from
August 6, 2026 23:33
3ec8bc2 to
dc6688c
Compare
folkertdev
commented
Aug 6, 2026
Comment on lines
+1236
to
+1247
| Arch::Sparc => { | ||
| std::assert_matches!(stability, CVariadicStatus::Unstable { .. }); | ||
| emit_ptr_va_arg( | ||
| bx, | ||
| addr, | ||
| target_ty, | ||
| PassMode::Direct, | ||
| SlotSize::Bytes4, | ||
| AllowHigherAlign::No, | ||
| ForceRightAdjust::No, | ||
| ) | ||
| } |
Contributor
Author
There was a problem hiding this comment.
Sparc is still gated by the c_variadic_experimental_arch feature.
The arguments to emit_ptr_va_arg here are based on the LLVM implementation. Many targets have an implementation of va_arg in Clang, but for sparc it is really LLVM that expands va_arg.
- it just loads from a pointer regardless of the size of the argument, hence unconditional
PassMode::Direct - The pointer is increased by just the
VTsize in bytes. Due to argument promotion, the smallest type that can actually be read usingva_argis 4 bytes, and no attempt is made to align to something higher than that. SoSlotSize::Bytes4. AllowHigherAlign::Yeswould align e.g. ani128to a 16-byte boundary. This function does not take the alignment into account at all. So,AllowHigherAlign::No- This setting is true on BE targets with a slot size of 8, where a 4-byte value could be either in the low or high bytes. Despite being a BE target, the setting is not relevant for sparc because all values that could be passed divide cleanly into 4-byte slots.
folkertdev
marked this pull request as ready for review
August 7, 2026 12:46
Collaborator
|
r? @khyperia rustbot has assigned @khyperia. Use Why was this reviewer chosen?The reviewer was selected based on:
|
Contributor
Author
|
cc target maintainer @jonathanpallant |
Contributor
Author
|
As context, I'd like to just stabilize c-variadic functions for this target, and for that we don't want to rely on LLVM's |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I've built GCC for the target and validated pretty extensively that this works. Using our helper does generate worse code for
i64unfortunately, I've reported that as llvm/llvm-project#214594. But, given that this is a tier-3 target etc. I don't think it makes sense to go out of our way to do better, we can just wait for LLVM to resolve that issue.