| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Make `AssocItem` aware of its impl kind
The general goal is to have fewer query dependencies by making `AssocItem` aware of its parent impl kind (inherent vs. trait) without having to query the parent def_kind.
See individual commits.
|
|
|
|
This schema is helpful for people writing custom target spec JSON. It
can provide autocomplete in the editor, and also serves as documentation
when there are documentation comments on the structs, as `schemars` will
put them in the schema.
|
|
match clang's `va_arg` assembly on arm targets
tracking issue: https://github.com/rust-lang/rust/issues/44930
For this example
```rust
#![feature(c_variadic)]
#[unsafe(no_mangle)]
unsafe extern "C" fn variadic(a: f64, mut args: ...) -> f64 {
let b = args.arg::<f64>();
let c = args.arg::<f64>();
a + b + c
}
```
We currently generate (via llvm):
```asm
variadic:
sub sp, sp, #12
stmib sp, {r2, r3}
vmov d0, r0, r1
add r0, sp, #4
vldr d1, [sp, #4]
add r0, r0, #15
bic r0, r0, #7
vadd.f64 d0, d0, d1
add r1, r0, #8
str r1, [sp]
vldr d1, [r0]
vadd.f64 d0, d0, d1
vmov r0, r1, d0
add sp, sp, #12
bx lr
```
LLVM is not doing a good job. In fact, it's well-known that LLVM's implementation of `va_arg` is kind of bad, and we implement it ourselves (based on clang) for many targets already. For arm, our own `emit_ptr_va_arg` saves 3 instructions.
Next, it turns out it's important for LLVM to explicitly start and end the lifetime of the `va_list`. In https://github.com/rust-lang/rust/pull/146059 I already end the lifetime, but when looking at this again, I noticed that it is important to also start it, see https://godbolt.org/z/EGqvKTTsK: failing to explicitly start the lifetime uses an extra register.
So, the combination of `emit_ptr_va_arg` with starting/ending the lifetime makes rustc emit exactly the instructions that clang generates::
```asm
variadic:
sub sp, sp, #12
stmib sp, {r2, r3}
vmov d16, r0, r1
vldr d17, [sp, #4]
vadd.f64 d16, d16, d17
vldr d17, [sp, #12]
vadd.f64 d16, d16, d17
vmov r0, r1, d16
add sp, sp, #12
bx lr
```
The arguments to `emit_ptr_va_arg` are based on [the clang implementation](https://github.com/llvm/llvm-project/blob/03dc2a41f3d9a500e47b513de5c5008c06860d65/clang/lib/CodeGen/Targets/ARM.cpp#L798-L844).
r? ``@workingjubilee`` (I can re-roll if your queue is too full, but you do seem like the right person here)
try-job: armhf-gnu
|
|
Misc LTO cleanups
Follow up to https://github.com/rust-lang/rust/pull/145955.
* Remove want_summary argument from `prepare_thin`.
Since https://github.com/rust-lang/rust/pull/133250 ThinLTO summary writing is instead done by `llvm_optimize`.
* Two minor cleanups
|
|
Use `Itertools::all_equal_value()` where applicable
Just a small cleanup.
We already have `itertools` as a dep in these crates, so might as well use another of its features.
Makes the code simpler IMHO :)
|
|
|
|
It is always false nowadays. ThinLTO summary writing is instead done by
llvm_optimize.
|
|
It is only used within cg_llvm.
|
|
|
|
|
|
|
|
|
|
A lot of places had special handling just in case they would get an
allocator module even though most of these places could never get one or
would have a trivial implementation for the allocator module. Moving all
handling of the allocator module to a single place simplifies things a
fair bit.
|
|
Making it participate in LTO would be incorrect if you compile a crate
as both a dylib (which needs it) and rlib (which must not include it) in
the same rustc invocation. With linker plugin LTO, the allocator shim
will still participate in LTO as it is safe to do so in that case.
|
|
|
|
Ensure we emit an allocator shim when only some crate types need one
Found this while trying to write a test for https://github.com/rust-lang/rust/pull/145955.
|
|
Allow `inline(always)` with a target feature behind a unstable feature `target_feature_inline_always`.
Rather than adding the inline always attribute to the function definition, we add it to the callsite. We can then check that the target features match and that the call would be safe to inline. If the function isn't inlined due to a mismatch, we emit a warning informing the user that the function can't be inlined due to the target feature mismatch.
See tracking issue rust-lang/rust#145574
|
|
Revert "Make `lto` and `linker-plugin-lto` work the same for `compiler_builtins`
This reverts commit cf8753e4f9c3597f04cd5d3aa261e4561d5378a6 (PR https://github.com/rust-lang/rust/pull/145368) and fix the regressions reported at rust-lang/rust#145981, rust-lang/rust#146109, and rust-lang/rust#146145.
|
|
|
|
`compiler_builtins`"
This reverts commit cf8753e4f9c3597f04cd5d3aa261e4561d5378a6 and fixes the
regressions reported.
|
|
explicitly end the lifetime of `va_list`
tracking issue: https://github.com/rust-lang/rust/issues/44930
split out from: https://github.com/rust-lang/rust/pull/144549
The `va_list` is created in the compiler itself when the variable argument list `...` is desugared, and hence the lifetime end is not inserted automatically. The value can't outlive the function in which it was created, so it is correct to end the lifetime here. Ending the lifetime explicitly also appears to give slightly better codegen in https://github.com/rust-lang/rust/pull/144549.
I also included a little drive-by improvement to not cast pointers to integers and back again.
r? codegen
|
|
|
|
|
|
|
|
exported
Previously it would attempt to export the allocator shim even linking
for a crate type which pulls in the allocator shim from a dylib rather
than locally defining it.
|
|
|
|
|
|
Move exporting of profiler and sanitizer symbols to the LLVM backend
Only the LLVM backend needs those specific symbols exported and it only needs them to be exported for LTO, not from cdylibs in general.
|
|
CFI: Make `lto` and `linker-plugin-lto` work the same for `compiler_builtins`
Fix rust-lang/rust#142284 by ensuring that `#![no_builtins]` crates can still emit bitcode when proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto) is used.
|
|
Don't export them from cdylibs. There is no need to do so and it
complicates exported_non_generic_symbols. In addition the GCC backend
likely uses different symbols and may potentially not even need us to
explicitly tell it to export the symbols it needs.
|
|
Port `#[link]` to the new attribute parsing infrastructure
Ports `link` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197
|
|
Ensure the coordinator thread terminates before its channels drop
Fixes rust-lang/rust#142949
Explanation: https://github.com/rust-lang/rust/issues/142949#issuecomment-3224573185
|
|
|
|
|
|
Co-authored-by: Jamie Cunliffe <Jamie.Cunliffe@arm.com>
|
|
Fix #142284 by ensuring that `#![no_builtins]` crates can still emit bitcode
when proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto) is used.
|
|
add a flag to codegen fn attrs for foreign items
r? `@ghost`
refiled to rerun CI
|
|
rustc_codegen_ssa: More comprehensive RISC-V ELF flags
This change implements more conformant, more comprehensive RISC-V ELF flags handling when generating certain object files directly from rustc.
* Use `"zca"` instead of `"c"`
The "Zca" extension (a subset of "C") is the minimal configuration for compressed instructions to set `EF_RISCV_RVC` flag.
* Set TSO flag from `"ztso"`
The "Ztso" extension denotes that the program depends on the RVTSO (Total Store Ordering) memory consistency model, which is stronger than the standard RVWMO (Weak Memory Ordering) consistency model and on ELF targets, we need to set `EF_RISCV_TSO` flag.
|
|
|
|
|
|
|
|
Don't show warnings from xcrun with -Zverbose-internals
These kinds of warnings can make our test suite fail spuriously, so if we want them, we'll need a different flag.
This was introduced in https://github.com/rust-lang/rust/pull/131477. Fixes https://github.com/rust-lang/rust/issues/145543.
r? apiraino
```@bors``` rollup
|
|
Handle unwinding fatal errors in codegen workers
Also directly unwind on fatal errors at the point they are emitted inside the codegen backends.
Fixes the coordinator ICE of https://github.com/rust-lang/rust/issues/132240, https://github.com/rust-lang/rust/issues/135075 and https://github.com/rust-lang/rust/issues/145800.
|
|
This commit implements more conformant, more comprehensive RISC-V ELF
flags handling when generating certain object files directly from rustc.
* Use "zca" instead of "c"
The "Zca" extension (a subset of "C") is the minimal configuration
for compressed instructions to set `EF_RISCV_RVC` flag.
* Set TSO flag from "ztso"
The "Ztso" extension denotes that the program depends on the RVTSO
(Total Store Ordering) memory consistency model, which is stronger
than the standard RVWMO (Weak Memory Ordering) consistency model and
on ELF targets, we need to set `EF_RISCV_TSO` flag.
|
|
|
|
These kinds of warnings can make our test suites fail, so if we want
them, we'll need a different flag.
|
|
raw-dylib-elf: set correct `DT_VERDEFNUM`
Previously it indicated a single version, regardless of their count.
Observed in: https://github.com/davidlattimore/wild/pull/1041
|
|
Previously it indicated a single version, regardless of their count.
Observed in: https://github.com/davidlattimore/wild/pull/1041
|
|
As opposed to passing it around through Result.
|
