about summary refs log tree commit diff
path: root/compiler/rustc_target/src/abi/call/riscv.rs
AgeCommit message (Collapse)AuthorLines
2024-10-11compiler: Empty out rustc_target::abiJubilee Young-367/+0
2024-09-03Add `warn(unreachable_pub)` to `rustc_target`.Nicholas Nethercote-1/+1
2024-05-06Refactor float `Primitive`s to a separate `Float` typebeetrees-1/+1
2024-04-08force_array -> is_consecutiveNikita Popov-10/+5
The actual ABI implication here is that in some cases the values are required to be "consecutive", i.e. must either all be passed in registers or all on stack (without padding). Adjust the code to either use Uniform::new() or Uniform::consecutive() depending on which behavior is needed. Then, when lowering this in LLVM, skip the [1 x i128] to i128 simplification if is_consecutive is set. i128 is the only case I'm aware of where this is problematic right now. If we find other cases, we can extend this (either based on target information or possibly just by not simplifying for is_consecutive entirely).
2024-04-08Fix argument ABI for overaligned structs on ppc64leNikita Popov-1/+6
When passing a 16 (or higher) aligned struct by value on ppc64le, it needs to be passed as an array of `i128` rather than an array of `i64`. This will force the use of an even starting register. For the case of a 16 byte struct with alignment 16 it is important that `[1 x i128]` is used instead of `i128` -- apparently, the latter will get treated similarly to `[2 x i64]`, not exhibiting the correct ABI. Add a `force_array` flag to `Uniform` to support this. The relevant clang code can be found here: https://github.com/llvm/llvm-project/blob/fe2119a7b08b6e468b2a67768904ea85b1bf0a45/clang/lib/CodeGen/Targets/PPC.cpp#L878-L884 https://github.com/llvm/llvm-project/blob/fe2119a7b08b6e468b2a67768904ea85b1bf0a45/clang/lib/CodeGen/Targets/PPC.cpp#L780-L784 I think the corresponding psABI wording is this: > Fixed size aggregates and unions passed by value are mapped to as > many doublewords of the parameter save area as the value uses in > memory. Aggregrates and unions are aligned according to their > alignment requirements. This may result in doublewords being > skipped for alignment. In particular the last sentence. Fixes https://github.com/rust-lang/rust/issues/122767.
2024-02-28Add `f16` and `f128` to `rustc_type_ir::FloatTy` and `rustc_abi::Primitive`Trevor Gross-1/+1
Make changes necessary to support these types in the compiler.
2023-11-03default Aggregate ABI to Indirect, and make sure it's never used for unsizedRalf Jung-0/+8
2023-09-19rustc_target/riscv: Fix passing of transparent unions with only one non-ZST ↵msizanoen-0/+11
member This ensures that `MaybeUninit<T>` has the same ABI as `T` when passed through an `extern "C"` function. Fixes https://github.com/rust-lang/rust/issues/115481.
2023-01-22abi: add `AddressSpace` field to `Primitive::Pointer`Erik Desjardins-1/+1
...and remove it from `PointeeInfo`, which isn't meant for this. There are still various places (marked with FIXMEs) that assume all pointers have the same size and alignment. Fixing this requires parsing non-default address spaces in the data layout string, which will be done in a followup.
2022-12-20rustc: Remove needless lifetimesJeremy Stucki-2/+2
2022-08-26Change `FnAbi::fixed_count` to a `u32`.Nicholas Nethercote-1/+1
2022-04-05Mark scalar layout unions so that backends that do not support partially ↵Oli Scherer-2/+2
initialized scalars can special case them.
2021-09-09Make `abi::Abi` `Copy` and remove a *lot* of refsAndreas Liljeqvist-2/+2
fix fix Remove more refs and clones fix more fix
2021-08-30rustc_target: remove `LayoutOf` bound from `TyAbiInterface`.Eduard-Mihai Burtescu-8/+2
2021-08-27rustc_target: rename `TyAndLayoutMethods` to `TyAbiInterface`.Eduard-Mihai Burtescu-6/+6
2021-08-27rustc_target: add lifetime parameter to `LayoutOf`.Eduard-Mihai Burtescu-5/+5
2020-11-21Replace sext() and zext() with single ext() methodbjorn3-2/+2
2020-11-21Replace ZExt and SExt flags with ArgExtension enumbjorn3-2/+2
Both flags are mutually exclusive
2020-11-08Collapse all uses of `target.options.foo` into `target.foo`Vadim Petrochenkov-1/+1
with an eye on merging `TargetOptions` into `Target`. `TargetOptions` as a separate structure is mostly an implementation detail of `Target` construction, all its fields logically belong to `Target` and available from `Target` through `Deref` impls.
2020-10-30Fix even more clippy warningsJoshua Nelson-4/+2
2020-08-30mv compiler to compiler/mark-0/+356