-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
c-variadic: make va_arg match on Arch exhaustive
#150831
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
base: main
Are you sure you want to change the base?
Conversation
|
|
| Arch::LoongArch32 => emit_ptr_va_arg( | ||
| Arch::RiscV32 if target.abi == Abi::Ilp32e => { | ||
| // FIXME: clang manually adjusts the alignment for this ABI. It notes: | ||
| // | ||
| // > To be compatible with GCC's behaviors, we force arguments with | ||
| // > 2×XLEN-bit alignment and size at most 2×XLEN bits like `long long`, | ||
| // > `unsigned long long` and `double` to have 4-byte alignment. This | ||
| // > behavior may be changed when RV32E/ILP32E is ratified. | ||
| bx.va_arg(addr.immediate(), bx.cx.layout_of(target_ty).llvm_type(bx.cx)) | ||
| } | ||
| Arch::RiscV32 | Arch::LoongArch32 => emit_ptr_va_arg( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @almindor @dkhayes117 @romancardenas @MabezDev @jessebraham @rmsyn
This special case for Ilp32e is unfortunate. Can any of you shine any light on this?
| Arch::Sparc64 => emit_ptr_va_arg( | ||
| bx, | ||
| addr, | ||
| target_ty, | ||
| if target_ty_size > 2 * 8 { PassMode::Indirect } else { PassMode::Direct }, | ||
| SlotSize::Bytes8, | ||
| AllowHigherAlign::Yes, | ||
| ForceRightAdjust::No, | ||
| ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
apparently there is no actual sparc64 rust target? just sparc is handled below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sparc64-unknown-linux-gnu?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right that does exist but does not get a page here
https://doc.rust-lang.org/beta/rustc/platform-support.html
and therefore apparently does not have a target maintainer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, afaik.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, also more specifically: "sparcv9" is a somewhat obfuscated (or "more correct", if you prefer) way of saying "sparc64": https://doc.rust-lang.org/nightly/rustc/platform-support/solaris.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, sparcv9-sun-solaris is 64 bit. Is there anything we should check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
github renders weirdly, there is some context in #150831 (review)
| Arch::SpirV => bug!("spirv does not support c-variadic functions"), | ||
|
|
||
| Arch::Mips | Arch::Mips32r6 | Arch::Mips64 | Arch::Mips64r6 => { | ||
| // FIXME: port MipsTargetLowering::lowerVAARG. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation is at https://github.com/llvm/llvm-project/blob/289a3292be0c6a3df86bcdf5be7dd05b79a5570c/llvm/lib/Target/Mips/MipsISelLowering.cpp#L2338
I suspect that is ultimately just emitVoidPtrVAArg but it's hard to tell.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @Gelbpunkt
Do you have any insights here? Perhaps we could make a PR to LLVM to clean things up?
| Arch::Sparc | Arch::Avr | Arch::M68k | Arch::Msp430 => { | ||
| // Clang uses the LLVM implementation for these architectures. | ||
| bx.va_arg(addr.immediate(), bx.cx.layout_of(target_ty).llvm_type(bx.cx)) | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That implementation is via DefaultABIInfo::EmitVAArg
To EmitVAArgInstr
To the LLVM CreateVAArg I believe this will eventually call expandVAArg
That really looks like emitVoidPtrVAArg to me, but it's hard to be completely sure.
This comment has been minimized.
This comment has been minimized.
f6f9040 to
b388d92
Compare
|
☔ The latest upstream changes (presumably #151144) made this pull request unmergeable. Please resolve the merge conflicts. |
b388d92 to
1d7b6e2
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello target maintainers, just making sure that you all see this. Overall we're just copying what clang does, but let us know if there is anything that doesn't look right or if you have useful background information. Otherwise maybe just thumbs-up the message to indicate that it looks good.
Some context you might be missing: I'm trying to stabilize c-variadic function definitions in rust. Historically, just relying on LLVM has been fragile, so we're replicating what clang does in this file. Doing (some of) our own codegen means we can make stronger promises about the exact behavior.
By making this match exhaustive, we'll know that we've at least considered all of the different targets.
| Arch::LoongArch32 => emit_ptr_va_arg( | ||
| Arch::RiscV32 if target.abi == Abi::Ilp32e => { | ||
| // FIXME: clang manually adjusts the alignment for this ABI. It notes: | ||
| // | ||
| // > To be compatible with GCC's behaviors, we force arguments with | ||
| // > 2×XLEN-bit alignment and size at most 2×XLEN bits like `long long`, | ||
| // > `unsigned long long` and `double` to have 4-byte alignment. This | ||
| // > behavior may be changed when RV32E/ILP32E is ratified. | ||
| bx.va_arg(addr.immediate(), bx.cx.layout_of(target_ty).llvm_type(bx.cx)) | ||
| } | ||
| Arch::RiscV32 | Arch::LoongArch32 => emit_ptr_va_arg( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @almindor @dkhayes117 @romancardenas @MabezDev @jessebraham @rmsyn
This special case for Ilp32e is unfortunate. Can any of you shine any light on this?
| Arch::SpirV => bug!("spirv does not support c-variadic functions"), | ||
|
|
||
| Arch::Mips | Arch::Mips32r6 | Arch::Mips64 | Arch::Mips64r6 => { | ||
| // FIXME: port MipsTargetLowering::lowerVAARG. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @Gelbpunkt
Do you have any insights here? Perhaps we could make a PR to LLVM to clean things up?
| Arch::Sparc64 => emit_ptr_va_arg( | ||
| bx, | ||
| addr, | ||
| target_ty, | ||
| if target_ty_size > 2 * 8 { PassMode::Indirect } else { PassMode::Direct }, | ||
| SlotSize::Bytes8, | ||
| AllowHigherAlign::Yes, | ||
| ForceRightAdjust::No, | ||
| ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
apparently there is no actual sparc64 rust target? just sparc is handled below.
tracking issue: #44930
Continuing from #150094, the more annoying cases remain. These are mostly very niche targets without Clang
va_argimplementations, and so it might just be easier to defer to LLVM instead of us getting the ABI subtly wrong. That does mean we cannot stabilize c-variadic on those targets I think.Alternatively we could ask target maintainers to contribute an implementation. I'd honestly prefer they make that change to LVM though (likely by just using
CodeGen::emitVoidPtrVAArg) that we can mirror.r? @workingjubilee