about summary refs log tree commit diff
path: root/compiler/rustc_codegen_ssa
AgeCommit message (Collapse)AuthorLines
2023-04-12Rollup merge of #110153 - DaniPopes:compiler-typos, r=NilstriebMatthias Krüger-4/+4
Fix typos in compiler I ran [`typos -w compiler`](https://github.com/crate-ci/typos) to fix typos in the `compiler` directory. Refs #110150
2023-04-11Rollup merge of #96971 - zhaixiaojuan:master, r=wesleywiserMichael Goulet-0/+5
Initial support for loongarch64-unknown-linux-gnu Hi, We hope to add a new port in rust for LoongArch. LoongArch intro LoongArch is a RISC style ISA which is independently designed by Loongson Technology in China. It is divided into two versions, the 32-bit version (LA32) and the 64-bit version (LA64). LA64 applications have application-level backward binary compatibility with LA32 applications. LoongArch is composed of a basic part (Loongson Base) and an expanded part. The expansion part includes Loongson Binary Translation (LBT), Loongson VirtualiZation (LVZ), Loongson SIMD EXtension (LSX) and Loongson Advanced SIMD EXtension(LASX). Currently the LA464 processor core supports LoongArch ISA and the Loongson 3A5000 processor integrates 4 64-bit LA464 cores. LA464 is a four-issue 64-bit high-performance processor core. It can be used as a single core for high-end embedded and desktop applications, or as a basic processor core to form an on-chip multi-core system for server and high-performance machine applications. Documentations: ISA: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html ABI: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html More docs can be found at: https://loongson.github.io/LoongArch-Documentation/README-EN.html Since last year, we have locally adapted two versions of rust, rust1.41 and rust1.57, and completed the test locally. I'm not sure if I'm submitting all the patches at once, so I split up the patches and here's one of the commits
2023-04-11Rollup merge of #109860 - zyedidia:riscv-relax, r=petrochenkovYuki Okushi-0/+1
Add support for RISC-V relax target feature This adds `relax` as an allowed RISC-V target feature. The relax feature in LLVM enables [linker relaxation](https://www.sifive.com/blog/all-aboard-part-3-linker-relaxation-in-riscv-toolchain), an optimization specific to RISC-V that allows global variable accesses to be resolved by the linker by using the global pointer (`gp`) register (rather than constructing the addresses from scratch for each access). Enabling `relax` will cause LLVM to emit relocations in the object file that support this. The feature can be enabled in rustc with `-C target-feature=+relax`. Currently this feature is disabled by default, but maybe it should be enabled by default since it is an easy performance improvement (but requires the `gp` register to be set up properly). GCC/Clang enable this feature by default (for both hosted/bare-metal targets), and include the `-mno-relax` flag to disable it (see [here](https://github.com/llvm/llvm-project/blob/466d554dcab39c3d42fe0c5b588b795e0e4b9d0d/clang/lib/Driver/ToolChains/Arch/RISCV.cpp#L145) for the code that enables it in Clang). I think it would make sense to enable by default, at least for all hosted targets since the `gp` register should be automatically set up by the runtime. For bare-metal targets, `gp` must be set up manually, so it is probably best to leave off by default to avoid breaking existing applications that do not set up `gp`. Leaving it disabled by default for all targets is also reasonable though. Let me know your thoughts. Thanks! Fixes #109426.
2023-04-11Preserve argument indexes when inlining MIRDavid Lattimore-6/+4
We store argument indexes on VarDebugInfo. Unlike the previous method of relying on the variable index to know whether a variable is an argument, this survives MIR inlining. We also no longer check if var.source_info.scope is the outermost scope. When a function gets inlined, the arguments to the inner function will no longer be in the outermost scope. What we care about though is whether they were in the outermost scope prior to inlining, which we know by whether we assigned an argument index.
2023-04-10Fix typos in compilerDaniPopes-4/+4
2023-04-10Rollup merge of #110021 - scottmcm:fix-110005, r=compiler-errorsDylan DPC-36/+96
Fix a couple ICEs in the new `CastKind::Transmute` code Check the sizes of the immediates, rather than the overall types, when deciding whether we can convert types without going through memory. Fixes #110005 Fixes #109992 Fixes #110032 cc `@matthiaskrgr`
2023-04-09Migrate `sess.opts.tests` uses to `sess.is_test_crate()`blyxyas-1/+1
2023-04-09Handle not all immediates having `abi::Scalar`sScott McMurray-12/+42
2023-04-08Auto merge of #109971 - WaffleLapkin:yeet_ownership, r=Nilstriebbors-6/+5
Yeet `owning_ref` Based on the discussions from https://github.com/rust-lang/rust/pull/109948 This replaces `owning_ref` with a far simpler & safer abstraction. Fixes #109974
2023-04-06Check `CastKind::Transmute` sizes in a better wayScott McMurray-31/+61
Fixes #110005
2023-04-06Use `FnOnce` for `slice_owned` instead of `Fn`Maybe Waffle-1/+1
2023-04-06Fix MSVC buildGary Guo-2/+4
2023-04-06Address review feedbackGary Guo-2/+2
2023-04-06Rename `Abort` terminator to `Terminate`Gary Guo-5/+5
Unify terminology used in unwind action and terminator, and reflect the fact that a nounwind panic is triggered instead of an immediate abort is triggered for this terminator.
2023-04-06Add `UnwindAction::Terminate`Gary Guo-83/+77
2023-04-06Add `UnwindAction::Unreachable`Gary Guo-22/+33
This also makes eval machine's `StackPopUnwind` redundant so that is replaced.
2023-04-06Refactor unwind from Option to a new enumGary Guo-25/+29
2023-04-05Use `OwnedSlice` instead of `owning_ref`Maybe Waffle-7/+6
2023-04-05Auto merge of #109843 - scottmcm:better-transmute, r=WaffleLapkinbors-20/+187
Allow `transmute`s to produce `OperandValue`s instead of needing `alloca`s LLVM can usually optimize these away, but especially for things like transmutes of newtypes it's silly to generate the `alloc`+`store`+`load` at all when it's actually a nop at LLVM level.
2023-04-04Allow `transmute`s to produce `OperandValue`s instead of always using `alloca`sScott McMurray-20/+187
LLVM can usually optimize these away, but especially for things like transmutes of newtypes it's silly to generate the `alloc`+`store`+`load` at all when it's actually a nop at LLVM level.
2023-04-04Auto merge of #109808 - jyn514:debuginfo-options, r=michaelwoeristerbors-1/+4
Extend -Cdebuginfo with new options and named aliases This is a rebase of https://github.com/rust-lang/rust/pull/83947, along with my best guess at what the new options mean. I tried to follow the LLVM source code to get a better idea but ran into quite a lot of trouble (https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/go-to-definition.20in.20src.2Fllvm-project.3F). The description for the original PR follows below. Note that the changes in this PR have already been through FCP: https://github.com/rust-lang/rust/pull/83947#issuecomment-878384979 Closes https://github.com/rust-lang/rust/pull/109311. Helps with https://github.com/rust-lang/rust/pull/104968. r? `@michaelwoerister` cc `@cuviper` --- The -Cdebuginfo=1 option was never line tables only and can't be due to backwards compatibility issues. This was clarified and an option for emitting line tables only was added. Additionally an option for emitting line info directives only was added, which is needed for some targets, i.e. nvptx. The debug info options should now behave similarly to clang's debug info options. Fix https://github.com/rust-lang/rust/issues/60020 Fix https://github.com/rust-lang/rust/issues/64405
2023-04-04Rollup merge of #109901 - cjgillot:validate-debuginfo, r=b-naberMichael Goulet-5/+9
Enforce VarDebugInfo::Place in MIR validation.
2023-04-04loongarch64: calculate the ELF header flagszhaixiaojuan-0/+4
2023-04-04Add loongarch64 to fn create_object_filezhaixiaojuan-0/+1
2023-04-03Enforce VarDebugInfo::Place in MIR validation.Camille GILLOT-5/+9
2023-04-02Use `&IndexSlice` instead of `&IndexVec` where possibleScott McMurray-5/+8
All the same reasons as for `[T]`: more general, less pointer chasing, and `&mut IndexSlice` emphasizes that it doesn't change *length*.
2023-04-02Add riscv relax target featureZachary Yedidia-0/+1
2023-04-01Use `FieldIdx` in various things related to aggregatesScott McMurray-6/+6
Shrank `AggregateKind` by 8 bytes on x64, since the active field of a union is tracked as an `Option<FieldIdx>` instead of `Option<usize>`.
2023-03-31Preserve, clarify, and extend debug informationJulia Tatz-1/+4
`-Cdebuginfo=1` was never line tables only and can't be due to backwards compatibility issues. This was clarified and an option for line tables only was added. Additionally an option for line info directives only was added, which is well needed for some targets. The debug info options should now behave the same as clang's debug info options.
2023-03-31Auto merge of #98112 - saethlin:mir-alignment-checks, r=oli-obkbors-0/+7
Insert alignment checks for pointer dereferences when debug assertions are enabled Closes https://github.com/rust-lang/rust/issues/54915 - [x] Jake tells me this sounds like a place to use `MirPatch`, but I can't figure out how to insert a new basic block with a new terminator in the middle of an existing basic block, using `MirPatch`. (if nobody else backs up this point I'm checking this as "not actually a good idea" because the code looks pretty clean to me after rearranging it a bit) - [x] Using `CastKind::PointerExposeAddress` is definitely wrong, we don't want to expose. Calling a function to get the pointer address seems quite excessive. ~I'll see if I can add a new `CastKind`.~ `CastKind::Transmute` to the rescue! - [x] Implement a more helpful panic message like slice bounds checking. r? `@oli-obk`
2023-03-30Rollup merge of #109347 - cjgillot:issue-109305, r=WaffleLapkinMichael Goulet-69/+46
Skip no_mangle if the item has no name. Fixes https://github.com/rust-lang/rust/issues/109305
2023-03-30Auto merge of #105587 - tgross35:once-cell-min, r=m-ou-sebors-1/+0
Partial stabilization of `once_cell` This PR aims to stabilize a portion of the `once_cell` feature: - `core::cell::OnceCell` - `std::cell::OnceCell` (re-export of the above) - `std::sync::OnceLock` This will leave `LazyCell` and `LazyLock` unstabilized, which have been moved to the `lazy_cell` feature flag. Tracking issue: https://github.com/rust-lang/rust/issues/74465 (does not fully close, but it may make sense to move to a new issue) Future steps for separate PRs: - ~~Add `#[inline]` to many methods~~ #105651 - Update cranelift usage of the `once_cell` crate - Update rust-analyzer usage of the `once_cell` crate - Update error messages discussing once_cell ## To be stabilized API summary ```rust // core::cell (in core/cell/once.rs) pub struct OnceCell<T> { .. } impl<T> OnceCell<T> { pub const fn new() -> OnceCell<T>; pub fn get(&self) -> Option<&T>; pub fn get_mut(&mut self) -> Option<&mut T>; pub fn set(&self, value: T) -> Result<(), T>; pub fn get_or_init<F>(&self, f: F) -> &T where F: FnOnce() -> T; pub fn into_inner(self) -> Option<T>; pub fn take(&mut self) -> Option<T>; } impl<T: Clone> Clone for OnceCell<T>; impl<T: Debug> Debug for OnceCell<T> impl<T> Default for OnceCell<T>; impl<T> From<T> for OnceCell<T>; impl<T: PartialEq> PartialEq for OnceCell<T>; impl<T: Eq> Eq for OnceCell<T>; ``` ```rust // std::sync (in std/sync/once_lock.rs) impl<T> OnceLock<T> { pub const fn new() -> OnceLock<T>; pub fn get(&self) -> Option<&T>; pub fn get_mut(&mut self) -> Option<&mut T>; pub fn set(&self, value: T) -> Result<(), T>; pub fn get_or_init<F>(&self, f: F) -> &T where F: FnOnce() -> T; pub fn into_inner(self) -> Option<T>; pub fn take(&mut self) -> Option<T>; } impl<T: Clone> Clone for OnceLock<T>; impl<T: Debug> Debug for OnceLock<T>; impl<T> Default for OnceLock<T>; impl<#[may_dangle] T> Drop for OnceLock<T>; impl<T> From<T> for OnceLock<T>; impl<T: PartialEq> PartialEq for OnceLock<T> impl<T: Eq> Eq for OnceLock<T>; impl<T: RefUnwindSafe + UnwindSafe> RefUnwindSafe for OnceLock<T>; unsafe impl<T: Send> Send for OnceLock<T>; unsafe impl<T: Sync + Send> Sync for OnceLock<T>; impl<T: UnwindSafe> UnwindSafe for OnceLock<T>; ``` No longer planned as part of this PR, and moved to the `rust_cell_try` feature gate: ```rust impl<T> OnceCell<T> { pub fn get_or_try_init<F, E>(&self, f: F) -> Result<&T, E> where F: FnOnce() -> Result<T, E>; } impl<T> OnceLock<T> { pub fn get_or_try_init<F, E>(&self, f: F) -> Result<&T, E> where F: FnOnce() -> Result<T, E>; } ``` I am new to this process so would appreciate mentorship wherever needed.
2023-03-29Stabilize a portion of 'once_cell'Trevor Gross-1/+0
Move items not part of this stabilization to 'lazy_cell' or 'once_cell_try'
2023-03-29Rollup merge of #109716 - scottmcm:field-to-fieldidx, r=oli-obkMatthias Krüger-4/+4
Move `mir::Field` → `abi::FieldIdx` The first PR for https://github.com/rust-lang/compiler-team/issues/606 This is just the move-and-rename, because it's plenty big already. Future PRs will start using `FieldIdx` more broadly, and concomitantly removing `FieldIdx::new`s.
2023-03-29Auto merge of #108089 - Zoxc:windows-tls, r=bjorn3bors-8/+49
Support TLS access into dylibs on Windows This allows access to `#[thread_local]` in upstream dylibs on Windows by introducing a MIR shim to return the address of the thread local. Accesses that go into an upstream dylib will call the MIR shim to get the address of it. `convert_tls_rvalues` is introduced in `rustc_codegen_ssa` which rewrites MIR TLS accesses to dummy calls which are replaced with calls to the MIR shims when the dummy calls are lowered to backend calls. A new `dll_tls_export` target option enables this behavior with a `false` value which is set for Windows platforms. This fixes https://github.com/rust-lang/rust/issues/84933.
2023-03-29Support TLS access into dylibs on WindowsJohn Kåre Alsaker-8/+49
2023-03-28Move `mir::Field` → `abi::FieldIdx`Scott McMurray-4/+4
The first PR for https://github.com/rust-lang/compiler-team/issues/606 This is just the move-and-rename, because it's plenty big-and-bitrotty already. Future PRs will start using `FieldIdx` more broadly, and concomitantly removing `FieldIdx::new`s.
2023-03-28Skip no_mangle if the item has no name.Camille GILLOT-1/+16
2023-03-28Reformat codegen_fn_attrs.Camille GILLOT-71/+33
2023-03-28[fix] don't panic on failure to acquire jobserver tokenDaniil Belov-2/+2
2023-03-27Bless tidyMaybe Waffle-1/+1
2023-03-27Rollup merge of #109582 - scottmcm:local-ref-pending, r=oli-obkMatthias Krüger-20/+26
Refactor: Separate `LocalRef` variant for not-evaluated-yet operands As I was reading through this, I noticed that almost every place that was using this needed to distinguish between Some vs None in the match arm anyway, so thought that separating the cases at the variant level might be clearer instead. I like how it ended up; let me know what you think!
2023-03-27Auto merge of #109091 - Nilstrieb:match-on-attr, r=cjgillotbors-293/+326
Cleanup `codegen_fn_attrs` The `match` control flow construct has been stable since 1.0, we should use it here. Sorry for the hard to review diff, I did try to at least split it into two commits. But looking at before-after side-by-side (instead of whatever github is doing) is probably the easiest way to make sure that I didn't forget about anything. On top of #109088, you can wait for that
2023-03-25Refactor: `VariantIdx::from_u32(0)` -> `FIRST_VARIANT`Scott McMurray-5/+4
Since structs are always `VariantIdx(0)`, there's a bunch of files where the only reason they had `VariantIdx` or `vec::Idx` imported at all was to get the first variant. So this uses a constant for that, and adds some doc-comments to `VariantIdx` while I'm there, since it doesn't have any today.
2023-03-24Refactor: Separate `LocalRef` variant for not-evaluated-yet operandsScott McMurray-20/+26
2023-03-24Auto merge of #109220 - nikic:poison, r=cuviperbors-4/+5
Use poison instead of undef In cases where it is legal, we should prefer poison values over undef values. This replaces undef with poison for aggregate construction and for uninhabited types. There are more places where we can likely use poison, but I wanted to stay conservative to start with. In particular the aggregate case is important for newer LLVM versions, which are not able to handle an undef base value during early optimization due to poison-propagation concerns. r? `@cuviper`
2023-03-24Rollup merge of #109515 - bzEq:aix-linker, r=petrochenkovMatthias Krüger-0/+174
Add AixLinker to support linking on AIX AIX linker has a different cli style from other existing linkers. It is documented in https://www.ibm.com/docs/en/aix/7.1?topic=l-ld-command.
2023-03-23A MIR transform that checks pointers are alignedBen Kimock-0/+7
2023-03-23Auto merge of #109538 - matthiaskrgr:rollup-ct58npj, r=matthiaskrgrbors-0/+1
Rollup of 8 pull requests Successful merges: - #106964 (Clarify `Error::last_os_error` can be weird) - #107718 (Add `-Z time-passes-format` to allow specifying a JSON output for `-Z time-passes`) - #107880 (Lint ambiguous glob re-exports) - #108549 (Remove issue number for `link_cfg`) - #108588 (Fix the ffi_unwind_calls lint documentation) - #109231 (Add `try_canonicalize` to `rustc_fs_util` and use it over `fs::canonicalize`) - #109472 (Add parentheses properly for method calls) - #109487 (Move useless_anynous_reexport lint into unused_imports) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2023-03-23Rollup merge of #107718 - Zoxc:z-time, r=nnethercoteMatthias Krüger-0/+1
Add `-Z time-passes-format` to allow specifying a JSON output for `-Z time-passes` This adds back the `-Z time` option as that is useful for [my rustc benchmark tool](https://github.com/Zoxc/rcb), reverting https://github.com/rust-lang/rust/pull/102725. It now uses nanoseconds and bytes as the units so it is renamed to `time-precise`.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 12:58:54 +0000