about summary refs log tree commit diff
path: root/compiler/rustc_target/src/callconv
AgeCommit message (Collapse)AuthorLines
2025-09-29Rollup merge of #147134 - workingjubilee:remove-explicit-abialign-deref, ↵Stuart Cook-7/+7
r=Zalathar remove explicit deref of AbiAlign for most methods Much of the compiler calls functions on Align projected from AbiAlign. AbiAlign impls Deref to its inner Align, so we can simplify these away. Also, it will minimize disruption when AbiAlign is removed. For now, preserve usages that might resolve to PartialOrd or PartialEq, as those have odd inference.
2025-09-28remove explicit deref of AbiAlign for most methodsJubilee Young-7/+7
Much of the compiler calls functions on Align projected from AbiAlign. AbiAlign impls Deref to its inner Align, so we can simplify these away. Also, it will minimize disruption when AbiAlign is removed. For now, preserve usages that might resolve to PartialOrd or PartialEq, as those have odd inference.
2025-09-27compiler: remove AbiAlign inside TargetDataLayoutJubilee Young-6/+6
This maintains AbiAlign usage in public API and most of the compiler, but direct access of these fields is now in terms of Align only.
2025-09-05Rollup merge of #145709 - heiher:issue-145692-1, r=jackh726Trevor Gross-32/+105
Fix LoongArch C function ABI when passing/returning structs containing floats Similar to RISC-V, LoongArch passes structs containing only one or two floats (or a float–integer pair) in registers, as long as each element fits into a single corresponding register. Before this PR, Rust did not check the actual offset of the second float or integer; instead, it assumed the standard offset based on the default alignment. However, since the offset can be affected by `#[repr(align(N))]` and `#[repr(packed)]`, this led to miscompilations (see rust-lang/rust#145692). This PR fixes the issue by explicitly specifying the offset for the remainder of the cast.
2025-08-26Use captures(address) instead of captures(none) for indirect argsNikita Popov-4/+4
While provenance cannot be captured through these arguments, the address / object identity can.
2025-08-21Fix LoongArch C function ABI when passing/returning structs containing floatsWANG Rui-32/+105
2025-08-20Tell LLVM about read-only capturesNikita Popov-0/+1
`&Freeze` parameters are not only `readonly` within the function, but any captures of the pointer can also only be used for reads. This can now be encoded using the `captures(address, read_provenance)` attribute.
2025-07-28use let chains in mir, resolve, targetKivooeo-48/+41
2025-07-07Auto merge of #143182 - xdoardo:more-addrspace, r=workingjubileebors-9/+9
Allow custom default address spaces and parse `p-` specifications in the datalayout string Some targets, such as CHERI, use as default an address space different from the "normal" default address space `0` (in the case of CHERI, [200 is used](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-877.pdf)). Currently, `rustc` does not allow to specify custom address spaces and does not take into consideration [`p-` specifications in the datalayout string](https://llvm.org/docs/LangRef.html#langref-datalayout). This patch tries to mitigate these problems by allowing targets to define a custom default address space (while keeping the default value to address space `0`) and adding the code to parse the `p-` specifications in `rustc_abi`. The main changes are that `TargetDataLayout` now uses functions to refer to pointer-related informations, instead of having specific fields for the size and alignment of pointers in the default address space; furthermore, the two `pointer_size` and `pointer_align` fields in `TargetDataLayout` are replaced with an `FxHashMap` that holds info for all the possible address spaces, as parsed by the `p-` specifications. The potential performance drawbacks of not having ad-hoc fields for the default address space will be tested in this PR's CI run. r? workingjubilee
2025-07-07compiler: Parse `p-` specs in datalayout string, allow definition of custom ↵Edoardo Marangoni-9/+9
default data address space
2025-07-05use `div_ceil` instead of manual logicFolkert de Vries-3/+3
2025-07-05use `is_multiple_of` instead of manual moduloFolkert de Vries-3/+3
2025-07-03setup CI and tidy to use typos for spellchecking and fix few typosklensy-1/+1
2025-06-16Fix RISC-V C function ABI when passing/returning structs containing floatsbeetrees-101/+178
2025-06-15Rollup merge of #142389 - beetrees:cranelift-arg-ext, r=bjorn3León Orell Valerian Liehr-2/+3
Apply ABI attributes on return types in `rustc_codegen_cranelift` - The [x86-64 System V ABI standard](https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build) doesn't sign/zero-extend integer arguments or return types. - But the de-facto standard as implemented by Clang and GCC is to sign/zero-extend arguments to 32 bits (but not return types). - Additionally, Apple targets [sign/zero-extend both arguments and return values to 32 bits](https://developer.apple.com/documentation/xcode/writing-64-bit-intel-code-for-apple-platforms#Pass-arguments-to-functions-correctly). - However, the `rustc_target` ABI adjustment code currently [unconditionally extends both arguments and return values to 32 bits](https://github.com/rust-lang/rust/blame/e703dff8fe220b78195c53478e83fb2f68d8499c/compiler/rustc_target/src/callconv/x86_64.rs#L240) on all targets. - This doesn't cause a miscompilation when compiling with LLVM as LLVM will ignore the `signext`/`zeroext` attribute when applied to return types on non-Apple x86-64 targets. - Cranelift, however, does not have a similar special case, requiring `rustc` to set the argument extension attribute correctly. - However, `rustc_codegen_cranelift` doesn't currently apply ABI attributes to return types at all, meaning `rustc_codegen_cranelift` will currently miscompile `i8`/`u8`/`i16`/`u16` returns on x86-64 Apple targets as those targets require sign/zero-extension of return types. This PR fixes the bug(s) by making the `rustc_target` x86-64 System V ABI only mark return types as sign/zero-extended on Apple platforms, while also making `rustc_codegen_cranelift` apply ABI attributes to return types. The RISC-V and s390x C ABIs also require sign/zero extension of return types, so this will fix those targets when building with `rustc_codegen_cranelift` too. r? `````@bjorn3`````
2025-06-14Remove all support for wasm's legacy ABIbjorn3-51/+4
2025-06-12Apply ABI attributes on return types in `rustc_codegen_cranelift`beetrees-2/+3
2025-06-08Rollup merge of #142053 - heiher:loong32-none, r=wesleywiserJubilee-2/+2
Add new Tier-3 targets: `loongarch32-unknown-none*` MCP: https://github.com/rust-lang/compiler-team/issues/865 NOTE: LoongArch32 ELF object support is available starting with object v0.37.0.
2025-06-06Add new Tier-3 targets: `loongarch32-unknown-none*`WANG Rui-2/+2
MCP: https://github.com/rust-lang/compiler-team/issues/865
2025-06-04x86 (32/64): go back to passing SIMD vectors by-ptrRalf Jung-22/+5
2025-06-03compiler: actually remove Conv now that it is irrelevantJubilee Young-101/+0
2025-06-03compiler: simplify TargetOptions ABI functionsJubilee Young-1/+0
`adjust_abi` is not needed and `is_abi_supported` can be a 1-liner.
2025-06-03compiler: change Conv to CanonAbiJubilee Young-6/+6
2025-06-03compiler: add AbiMapJubilee Young-0/+1
- Add AbiMapping for encoding the nuance of deprecated ABIs
2025-05-17Rollup merge of #135808 - tiif:conv_display, r=workingjubileeMatthias Krüger-0/+32
Implement Display for ``rustc_target::callconv::Conv`` Follow up of https://github.com/rust-lang/rust/pull/133103#discussion_r1885552854
2025-05-12Use unreachable instead of panictiif-1/+1
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
2025-04-07mitigate MSVC unsoundness by not emitting alignment attributes on win32-msvc ↵Ralf Jung-0/+1
targets also mention the MSVC alignment issue in platform-support.md
2025-04-06remove compiler support for `extern "rust-intrinsic"` blocksSkgland-29/+15
2025-04-04Rollup merge of #138949 - madsmtm:rename-to-darwin, r=WaffleLapkinMatthias Krüger-2/+2
Rename `is_like_osx` to `is_like_darwin` Replace `is_like_osx` with `is_like_darwin`, which more closely describes reality (OS X is the pre-2016 name for macOS, and is by now quite outdated; Darwin is the overall name for the OS underlying Apple's macOS, iOS, etc.). ``@rustbot`` label O-apple r? compiler
2025-03-25Rename `is_like_osx` to `is_like_darwin`Mads Marquart-2/+2
2025-03-25make -Zwasm-c-abi=legacy suppress the lintRalf Jung-1/+1
2025-03-25add FCW to warn about wasm ABI transitionRalf Jung-0/+3
2025-03-12Remove invalid Convtiif-9/+8
2025-03-12fmttiif-8/+8
2025-03-12Implement Display by mapping Conv to ExternAbitiif-26/+27
2025-03-12impl Display for Convtiif-0/+32
2025-03-07Rollup merge of #137363 - workingjubilee:untangle-x86-abi-impl, r=jieyouxuJacob Pratt-23/+89
compiler: factor Windows x86-32 ABI impl into its own file While it shares more than zero code with the SysV x86-32 ABI impl, there is no particular reason to organize wildly different ABIs using if-else in the same function.
2025-03-05compiler: factor Windows x86-32 ABI impl into its own fileJubilee Young-23/+89
While it shares more than zero code with the SysV x86-32 ABI impl, there is no particular reason to organize wildly different ABIs using if-else in the same function.
2025-02-28rename BackendRepr::Vector → SimdVectorRalf Jung-13/+13
2025-02-20Rollup merge of #137318 - bjorn3:cg_clif_abi_workaround, r=workingjubileeJubilee-1/+3
Workaround Cranelift not yet properly supporting vectors smaller than 128bit While it would technically be possible to workaround this in cg_clif, it quickly becomes very messy and would likely cause correctness issues. Working around it in rustc instead is much simper and won't have any negative impact for code running on stable as vectors smaller than 128bit can only be made on nightly using core::simd or #[repr(simd)].
2025-02-20Remove `BackendRepr::Uninhabited`, replaced with an `uninhabited: bool` ↵Zachary S-10/+5
field in `LayoutData`. Also update comments that refered to BackendRepr::Uninhabited.
2025-02-20Workaround Cranelift not yet properly supporting vectors smaller than 128bitbjorn3-1/+3
While it would technically be possible to workaround this in cg_clif, it quickly becomes very messy and would likely cause correctness issues. Working around it in rustc instead is much simper and won't have any negative impact for code running on stable as vectors smaller than 128bit can only be made on nightly using core::simd or #[repr(simd)].
2025-02-19Rollup merge of #137094 - RalfJung:softfloat-means-no-simd, r=tgross35Matthias Krüger-6/+10
x86_win64 ABI: do not use xmm0 with softfloat ABI This adjusts https://github.com/rust-lang/rust/pull/134290 to not apply the new logic to targets marked as "softfloat". That fixes most instances of the issue brought up [here](https://github.com/rust-lang/rust/issues/116558#issuecomment-2661027437). r? `@tgross35`
2025-02-19x86_win64 ABI: do not use xmm0 with softfloat ABIRalf Jung-6/+10
2025-02-18x86-sse2 ABI: use SSE registers for floats and SIMDRalf Jung-47/+85
2025-02-12Rollup merge of #136807 - ↵Jacob Pratt-4/+2
workingjubilee:merge-gpus-to-get-the-arcradeongeforce, r=bjorn3 compiler: internally merge `PtxKernel` into `GpuKernel` r? ``@bjorn3`` for review
2025-02-10compiler: die immediately instead of handling unknown target codegenJubilee Young-22/+3
We cannot produce anything useful if asked to compile unknown targets. We should handle the error immediately at the point of discovery instead of propagating it upward, and preferably in the simplest way: Die. This allows cleaning up our "error-handling" spread across 5 crates.
2025-02-09compiler: internally merge `Conv::PtxKernel` into `GpuKernel`Jubilee Young-4/+2
It is speculated that these two can be conceptually merged, and it can start by ripping out rustc's notion of the PtxKernel call convention. Leave the ExternAbi for now, but the nvptx target now should see it as just a different way to spell Conv::GpuKernel.
2025-02-07compiler: remove reexports from rustc_target::callconvJubilee Young-3/+2
2025-02-07compiler: remove rustc_target::abi entirelyJubilee Young-22/+22
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 22:21:19 +0000