| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add `f16` inline asm support for LoongArch
r? `````@Amanieu`````
|
|
r=workingjubilee,saethlin
Move metadata object generation for dylibs to the linker code
This deduplicates some code between codegen backends and may in the future allow adding extra metadata that is only known at link time.
Prerequisite of https://github.com/rust-lang/rust/issues/96708.
|
|
|
|
intrinsics list
|
|
|
|
Simplify implementation of Rust intrinsics by using type parameters in the cache
The current implementation of intrinsics have a lot of duplication to handle different overloads of overloaded LLVM intrinsic. This PR uses the **base name and the type parameters** in the cache instead of the full, overloaded name. This has the benefit that `call_intrinsic` doesn't need to provide the full name, rather the type parameters (which is most of the time more available). This uses `LLVMIntrinsicCopyOverloadedName2` to get the overloaded name from the base name and the type parameters, and only uses it to declare the function.
(originally was part of rust-lang/rust#140763, split off later)
`@rustbot` label A-codegen A-LLVM
r? codegen
|
|
|
|
add `extern "custom"` functions
tracking issue: rust-lang/rust#140829
previous discussion: https://github.com/rust-lang/rust/issues/140566
In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.
The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.
At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.
r? `@traviscross`
cc `@tgross35`
try-job: x86_64-apple-2
|
|
retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features
`-Zretpoline` and `-Zretpoline-external-thunk` flags are target modifiers (tracked to be equal in linked crates).
* Enables target features for `-Zretpoline-external-thunk`:
`+retpoline-external-thunk`, `+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
* Enables target features for `-Zretpoline`:
`+retpoline-indirect-branches`, `+retpoline-indirect-calls`.
It corresponds to clang -mretpoline & -mretpoline-external-thunk flags.
Also this PR forbids to specify those target features manually (warning).
Issue: rust-lang/rust#116852
|
|
|
|
|
|
|
|
enable retpoline-related target features
|
|
Remove all unused feature gates from the compiler
|
|
store `target.min_global_align` as an `Align`
Parse the alignment properly when the target is defined/parsed, and error out on invalid alignment values. That means this work doesn't need to happen for every global in each backend.
|
|
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.
|
|
|
|
|
|
MCP: https://github.com/rust-lang/compiler-team/issues/865
|
|
Make #[used(linker)] the default on ELF too
`#[used]` currently is an alias for `#[used(linker)]` on all platforms except ELF based ones where it is an alias for `#[used(compiler)]`. The latter has surprising behavior and the LLVM LangRef explicitly states that it "should only be used in rare circumstances, and should not be exposed to source languages." [^2]
The reason `#[used]` still was an alias to `#[used(compiler)]` on ELF is because the gold linker has issues with it. Luckily gold has been deprecated with GCC 15 [^1] and seems to be unable to bootstrap rustc anyway [^3]. As such we shouldn't really care about supporting gold.
This would also allow re-enabling start-stop-gc with lld.
cc https://github.com/rust-lang/rust/issues/93798
Likely fixes https://github.com/rust-lang/rust/issues/85045
[^1]: https://lists.gnu.org/archive/html/info-gnu/2025-02/msg00001.html
[^2]: https://llvm.org/docs/LangRef.html#the-llvm-compiler-used-global-variable
[^3]: https://github.com/rust-lang/rust/issues/139425
|
|
#[used] currently is an alias for #[used(linker)] on all platforms
except ELF based ones where it is an alias for #[used(compiler)]. The
latter has surprising behavior and the LLVM LangRef explicitly states
that it "should only be used in rare circumstances, and should not be
exposed to source languages."
The reason #[used] still was an alias to #[used(compiler)] on ELF is
because the gold linker has issues with it. Luckily gold has been
deprecated with GCC 15 and seems to be unable to bootstrap rustc anyway.
As such we shouldn't really care about supporting gold.
|
|
r=workingjubilee
Change `tag_field` to `FieldIdx` in `Variants::Multiple`
It was already available as a generic parameter anyway, and it's not like we'll ever put a tag in the 5-billionth field.
This is a first part of pulling smaller pieces out of rust-lang/rust#138759, so
r? workingjubilee
|
|
It was already available as a generic parameter anyway, and it's not like we'll ever put a tag in the 5-billionth field.
|
|
add s390x z17 target features
tracking issue: https://github.com/rust-lang/rust/issues/130869
earlier target features were added in https://github.com/rust-lang/rust/pull/135630, and https://github.com/rust-lang/rust/issues/135413#issuecomment-2886439455 has some extra context on these new features.
r? ``@ghost``
cc ``@uweigand``
|
|
Replace ad-hoc ABI "adjustments" with an `AbiMap` to `CanonAbi`
Our `conv_from_spec_abi`, `adjust_abi`, and `is_abi_supported` combine to give us a very confusing way of reasoning about what _actual_ calling convention we want to lower our code to and whether we want to compile the resulting code at all. Instead of leaving this code as a miniature adventure game in which someone tries to combine stateful mutations into a Rube Goldberg machine that will let them escape the maze and arrive at the promised land of codegen, we let `AbiMap` devour this complexity. Once you have an `AbiMap`, you can answer which `ExternAbi`s will lower to what `CanonAbi`s (and whether they will lower at all).
Removed:
- `conv_from_spec_abi` replaced by `AbiMap::canonize_abi`
- `adjust_abi` replaced by same
- `Conv::PreserveAll` as unused
- `Conv::Cold` as unused
- `enum Conv` replaced by `enum CanonAbi`
target-spec.json changes:
- If you have a target-spec.json then now your "entry-abi" key will be specified in terms of one of the `"{abi}"` strings Rust recognizes, e.g.
```json
"entry-abi": "C",
"entry-abi": "win64",
"entry-abi": "aapcs",
```
|
|
|
|
This deduplicates some code between codegen backends and may in the
future allow adding extra metadata that is only known at link time.
|
|
And move passing it to the linker to the driver code.
|
|
It is only used within cg_llvm.
|
|
It is only used within cg_llvm.
|
|
Improve intrinsic handling in cg_ssa (part 2)
* Avoid computing function type and signature for intrinsics where possible
* Nicer handling of bool returning intrinsics
Follow up to https://github.com/rust-lang/rust/pull/141404
|
|
implement `va_arg` for `powerpc`
tracking issue: https://github.com/rust-lang/rust/issues/44930
The llvm `va_arg` implementation is well-known to have serious limitations. Some planned changes to rust's `VaList` make it much more likely that LLVM miscompiles `va_arg`, so this PR adds support for the various powerpc targets. Now at least the targets that `core` has explicit support for will continue to work.
For `powerpc` (the 32-bit variant) this implementation also fixes a bug where only up to 20 variadic arguments were supported.
Locally (with qemu), these targets now pass the tests in https://github.com/rust-lang/rust/blob/master/tests/run-make/c-link-to-rust-va-list-fn/checkrust.rs. That test does not actually run for the powerpc targets in CI though.
The implementation is based on clang:
- handling of big endian architectures https://github.com/llvm/llvm-project/blob/3c8089d1ea53232d5a7cdc33f0cb43ef7d6f723b/clang/lib/CodeGen/ABIInfoImpl.cpp#L191-L193
- 64-bit https://github.com/llvm/llvm-project/blob/3c8089d1ea53232d5a7cdc33f0cb43ef7d6f723b/clang/lib/CodeGen/Targets/PPC.cpp#L969
- 32-bit https://github.com/llvm/llvm-project/blob/3c8089d1ea53232d5a7cdc33f0cb43ef7d6f723b/clang/lib/CodeGen/Targets/PPC.cpp#L430
cc `@daltenty` (target maintainer)
r? `@workingjubilee`
`@rustbot` label: +F-c_variadic
|
|
This actually fixes a bug where before only 20 arguments could be passed. As far as I can tell, an arbitrary number of arguments is now supported
|
|
|
|
rustc_codegen_llvm: use `threadlocal.address` intrinsic to access TLS
Fixes #136044
r? `@nikic`
|
|
|
|
|
|
|
|
This avoids having to get the function signature.
|
|
implement `va_arg` for x86_64 systemv
tracking issue: https://github.com/rust-lang/rust/issues/44930
Turns out LLVM's `va_arg` is also unreliable for this target.
https://github.com/llvm/llvm-project/issues/141361
So, like clang, we implement our own. I used
- the spec at https://gitlab.com/x86-psABIs/x86-64-ABI
- the clang implementation at https://github.com/llvm/llvm-project/blob/9a440f84773c56d3803f330774acb2b4f471d5b4/clang/lib/CodeGen/Targets/X86.cpp#L3041
We can take a bunch of shortcuts because the return type of `va_list` must implement `VaArgSafe`. I also extended some of the tests, because up to 11 floats can be stored in the `reg_safe_area` for this calling convention.
r? `@workingjubilee`
`@rustbot` label +F-c_variadic
try-job: x86_64-apple-1
|
|
atomic_load intrinsic: use const generic parameter for ordering
We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that!
This PR only converts `load`, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics.
The first two commits are preparation and could be a separate PR if you prefer.
`@BoxyUwU` -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer...
`@bjorn3` it seems like the cranelift backend entirely ignores the ordering?
|
|
Turns out LLVM's `va_arg` is also unreliable for this target, so we need
our own implementation.
|
|
|
|
|
|
|
|
|
|
There is no safety contract and I don't think any of them can actually
cause UB in more ways than passing malicious source code to rustc can.
While LtoModuleCodegen::optimize says that the returned ModuleCodegen
points into the LTO module, the LTO module has already been dropped by
the time this function returns, so if the returned ModuleCodegen indeed
points into the LTO module, we would have seen crashes on every LTO
compilation, which we don't. As such the comment is outdated.
|
|
|
|
|
|
|
