Subtree sync for rustc_codegen_cranelift #136715

bjorn3 · 2025-02-07T21:02:42Z

The main highlights this time are a Cranelift update and a fix for a warning that the x87 feature is not enabled.

@rustbot label +A-codegen +A-cranelift +T-compiler

…acy extern "rust-intrinsic" blocks

…clif-2025-01-20

…lfJung Partial progress on rust-lang#132735: Replace extern "rust-intrinsic" with #[rustc_intrinsic] across the codebase Part of rust-lang#132735: Replace `extern "rust-intrinsic"` with `#[rustc_intrinsic]` macro - Updated all instances of `extern "rust-intrinsic"` to use the `#[rustc_intrinsic]` macro. - Skipped `.md` files and test files to avoid unnecessary changes.

…bjorn3 Subtree sync for rustc_codegen_cranelift Nothing too exciting this time, but this includes a fix for a linker hang on Windows: rust-lang/rustc_codegen_cranelift#1554 r? ``@ghost`` ``@rustbot`` label +A-codegen +A-cranelift +T-compiler

These may cause tests to fail. Disable them.

Ignore global git hooks when importing rust-lang/rust git repo

…rors remove support for the (unstable) #[start] attribute As explained by `@Noratrieb:` `#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction. I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple: - `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail) - `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things *anyways* `#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on ~~Windows~~ wasm, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program. So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving *any* stability guarantees on), and where there's a pretty easy way to get things working without it in the first place. Note that this feature has **not** been RFCed in the first place. *This comment was posted [in May](rust-lang#29633 (comment)) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.* Closes rust-lang#29633 try-job: x86_64-gnu-nopt try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: test-various

Clang and GCC both return `i128` in xmm0 on windows-msvc and windows-gnu. Currently, Rust returns the type on the stack. Add a calling convention adjustment so we also return scalar `i128`s using the vector ABI, which makes our `i128` compatible with C. In the future, Clang may change to return `i128` on the stack for its `-msvc` targets (more at [1]). If this happens, the change here will need to be adjusted to only affect MinGW. Link: rust-lang#134288

…orn3,wesleywiser Windows x86: Change i128 to return via the vector ABI Clang and GCC both return `i128` in xmm0 on windows-msvc and windows-gnu. Currently, Rust returns the type on the stack. Add a calling convention adjustment so we also return scalar `i128`s using the vector ABI, which makes our `i128` compatible with C. In the future, Clang may change to return `i128` on the stack for its `-msvc` targets (more at [1]). If this happens, the change here will need to be adjusted to only affect MinGW. Link: rust-lang#134288 (does not fix) [1] try-job: x86_64-msvc try-job: x86_64-msvc-ext1 try-job: x86_64-mingw-1 try-job: x86_64-mingw-2

… bound vars

Co-authored-by: FedericoBruzzone <federico.bruzzone.i@gmail.com>

Fix deduplication mismatches in vtables leading to upcasting unsoundness We currently have two cases where subtleties in supertraits can trigger disagreements in the vtable layout, e.g. leading to a different vtable layout being accessed at a callsite compared to what was prepared during unsizing. Namely: ### rust-lang#135315 In this example, we were not normalizing supertraits when preparing vtables. In the example, ``` trait Supertrait<T> { fn _print_numbers(&self, mem: &[usize; 100]) { println!("{mem:?}"); } } impl<T> Supertrait<T> for () {} trait Identity { type Selff; } impl<Selff> Identity for Selff { type Selff = Selff; } trait Middle<T>: Supertrait<()> + Supertrait<T> { fn say_hello(&self, _: &usize) { println!("Hello!"); } } impl<T> Middle<T> for () {} trait Trait: Middle<<() as Identity>::Selff> {} impl Trait for () {} fn main() { (&() as &dyn Trait as &dyn Middle<()>).say_hello(&0); } ``` When we prepare `dyn Trait`, we see a supertrait of `Middle<<() as Identity>::Selff>`, which itself has two supertraits `Supertrait<()>` and `Supertrait<<() as Identity>::Selff>`. These two supertraits are identical, but they are not duplicated because we were using structural equality and *not* considering normalization. This leads to a vtable layout with two trait pointers. When we upcast to `dyn Middle<()>`, those two supertraits are now the same, leading to a vtable layout with only one trait pointer. This leads to an offset error, and we call the wrong method. ### rust-lang#135316 This one is a bit more interesting, and is the bulk of the changes in this PR. It's a bit similar, except it uses binder equality instead of normalization to make the compiler get confused about two vtable layouts. In the example, ``` trait Supertrait<T> { fn _print_numbers(&self, mem: &[usize; 100]) { println!("{mem:?}"); } } impl<T> Supertrait<T> for () {} trait Trait<T, U>: Supertrait<T> + Supertrait<U> { fn say_hello(&self, _: &usize) { println!("Hello!"); } } impl<T, U> Trait<T, U> for () {} fn main() { (&() as &'static dyn for<'a> Trait<&'static (), &'a ()> as &'static dyn Trait<&'static (), &'static ()>) .say_hello(&0); } ``` When we prepare the vtable for `dyn for<'a> Trait<&'static (), &'a ()>`, we currently consider the PolyTraitRef of the vtable as the key for a supertrait. This leads two two supertraits -- `Supertrait<&'static ()>` and `for<'a> Supertrait<&'a ()>`. However, we can upcast[^up] without offsetting the vtable from `dyn for<'a> Trait<&'static (), &'a ()>` to `dyn Trait<&'static (), &'static ()>`. This is just instantiating the principal trait ref for a specific `'a = 'static`. However, when considering those supertraits, we now have only one distinct supertrait -- `Supertrait<&'static ()>` (which is deduplicated since there are two supertraits with the same substitutions). This leads to similar offsetting issues, leading to the wrong method being called. [^up]: I say upcast but this is a cast that is allowed on stable, since it's not changing the vtable at all, just instantiating the binder of the principal trait ref for some lifetime. The solution here is to recognize that a vtable isn't really meaningfully higher ranked, and to just treat a vtable as corresponding to a `TraitRef` so we can do this deduplication more faithfully. That is to say, the vtable for `dyn for<'a> Tr<'a>` and `dyn Tr<'x>` are always identical, since they both would correspond to a set of free regions on an impl... Do note that `Tr<for<'a> fn(&'a ())>` and `Tr<fn(&'static ())>` are still distinct. ---- There's a bit more that can be cleaned up. In codegen, we can stop using `PolyExistentialTraitRef` basically everywhere. We can also fix SMIR to stop storing `PolyExistentialTraitRef` in its vtable allocations. As for testing, it's difficult to actually turn this into something that can be tested with `rustc_dump_vtable`, since having multiple supertraits that are identical is a recipe for ambiguity errors. Maybe someone else is more creative with getting that attr to work, since the tests I added being run-pass tests is a bit unsatisfying. Miri also doesn't help here, since it doesn't really generate vtables that are offset by an index in the same way as codegen. r? `@lcnr` for the vibe check? Or reassign, idk. Maybe let's talk about whether this makes sense. <sup>(I guess an alternative would also be to not do any deduplication of vtable supertraits (or only a really conservative subset) rather than trying to normalize and deduplicate more faithfully here. Not sure if that works and is sufficient tho.)</sup> cc `@steffahn` -- ty for the minimizations cc `@WaffleLapkin` -- since you're overseeing the feature stabilization :3 Fixes rust-lang#135315 Fixes rust-lang#135316

… enabled Similar to how the alignment is already checked, this adds a check for null pointer dereferences in debug mode. It is implemented similarly to the alignment check as a MirPass. This is related to a 2025H1 project goal for better UB checks in debug mode: rust-lang/rust-project-goals#177.

Insert null checks for pointer dereferences when debug assertions are enabled Similar to how the alignment is already checked, this adds a check for null pointer dereferences in debug mode. It is implemented similarly to the alignment check as a `MirPass`. This inserts checks in the same places as the `CheckAlignment` pass and additionally also inserts checks for `Borrows`, so code like ```rust let ptr: *const u32 = std::ptr::null(); let val: &u32 = unsafe { &*ptr }; ``` will have a check inserted on dereference. This is done because null references are UB. The alignment check doesn't cover these places, because in `&(*ptr).field`, the exact requirement is that the final reference must be aligned. This is something to consider further enhancements of the alignment check. For now this is implemented as a separate `MirPass`, to make it easy to disable this check if necessary. This is related to a 2025H1 project goal for better UB checks in debug mode: rust-lang/rust-project-goals#177. r? `@saethlin`

…oli-obk Implement MIR lowering for unsafe binders This is the final bit of the unsafe binders puzzle. It implements MIR, CTFE, and codegen for unsafe binders, and enforces that (for now) they are `Copy`. Later on, I'll introduce a new trait that relaxes this requirement to being "is `Copy` or `ManuallyDrop<T>`" which more closely models how we treat union fields. Namely, wrapping unsafe binders is now `Rvalue::WrapUnsafeBinder`, which acts much like an `Rvalue::Aggregate`. Unwrapping unsafe binders are implemented as a MIR projection `ProjectionElem::UnwrapUnsafeBinder`, which acts much like `ProjectionElem::Field`. Tracking: - rust-lang#130516

…clif-2025-02-07

rustbot · 2025-02-07T21:02:48Z

There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

You can start a rebase with the following commands:

$ # rebase
$ git pull --rebase https://github.com/rust-lang/rust.git master
$ git push --force-with-lease

The following commits are merge commits:

rustbot · 2025-02-07T21:02:48Z

Error: Parsing relabel command in comment failed: ...'-compiler<' | error: a label delta at >| '!-- homu-i'...

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

bjorn3 · 2025-02-07T21:02:54Z

@bors r+ p=1 subtree sync

bors · 2025-02-07T21:02:57Z

📌 Commit cac271f has been approved by bjorn3

It is now in the queue for this repository.

…bjorn3 Subtree sync for rustc_codegen_cranelift The main highlights this time are a Cranelift update and a fix for a warning that the x87 feature is not enabled. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler

…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#131282 (std: detect stack overflows in TLS destructors on UNIX) - rust-lang#135696 (std: move `io` module out of `pal`, get rid of `sys_common::io`) - rust-lang#136099 (Optimize `Rc::<str>::default()` implementation) - rust-lang#136200 (Generate correct terminate block under Wasm EH) - rust-lang#136626 (create `initial_rustdoc` field in `Build`) - rust-lang#136657 (Make empty-line-after an early clippy lint) - rust-lang#136679 (ci: Use largedisk for loongarch) - rust-lang#136715 (Subtree sync for rustc_codegen_cranelift) r? `@ghost` `@rustbot` modify labels: rollup

…bjorn3 Subtree sync for rustc_codegen_cranelift The main highlights this time are a Cranelift update and a fix for a warning that the x87 feature is not enabled. r? ``@ghost`` ``@rustbot`` label +A-codegen +A-cranelift +T-compiler

…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#135696 (std: move `io` module out of `pal`, get rid of `sys_common::io`) - rust-lang#136099 (Optimize `Rc::<str>::default()` implementation) - rust-lang#136200 (Generate correct terminate block under Wasm EH) - rust-lang#136626 (create `initial_rustdoc` field in `Build`) - rust-lang#136657 (Make empty-line-after an early clippy lint) - rust-lang#136679 (ci: Use largedisk for loongarch) - rust-lang#136715 (Subtree sync for rustc_codegen_cranelift) r? `@ghost` `@rustbot` modify labels: rollup

bors · 2025-02-08T18:23:43Z

⌛ Testing commit cac271f with merge 73bf794...

bors · 2025-02-08T21:10:36Z

☀️ Test successful - checks-actions
Approved by: bjorn3
Pushing 73bf794 to master...

rust-timer · 2025-02-08T23:37:25Z

Finished benchmarking commit (73bf794): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -3.1%, secondary 2.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.2%	[2.2%, 2.2%]	1
Improvements ✅ (primary)	-3.1%	[-3.1%, -3.1%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-3.1%	[-3.1%, -3.1%]	1

Cycles

Results (secondary 2.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	6.2%	[3.2%, 9.2%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.1%	[-2.2%, -2.1%]	2
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 780.482s -> 779.565s (-0.12%)
Artifact size: 329.09 MiB -> 329.13 MiB (0.01%)

vayunbiyani and others added 30 commits January 20, 2025 09:15

Updated several files to use rust intrinsic macros instead of the leg…

68283cc

…acy extern "rust-intrinsic" blocks

Merge commit '728bc27f32c05ac8a9b5eb33fd101e479072984f' into sync_cg_…

f141118

…clif-2025-01-20

Ignore global git hooks when importing rust-lang/rust git repo

ffe312e

These may cause tests to fail. Disable them.

Merge pull request rust-lang#1556 from jyn514/git-hooks

adcd89a

Ignore global git hooks when importing rust-lang/rust git repo

Merge branch 'sync_from_rust'

65b3b0e

remove support for the #[start] attribute

c4a3398

Sync from rust 649b995

c52eee7

Rustup to rustc 1.86.0-nightly (649b995 2025-01-22)

ccf8977

Fix rustc test suite

50c14ce

Add missing entry to builtin_functions

eeb7930

Update to Cranelift 0.116

e7b1853

Fix cg_clif testing coretests

996d570

Change collect_and_partition_mono_items tuple return type to a struct

0ef7ea2

Do not treat vtable supertraits as distinct when bound with different…

9f44caa

… bound vars

Use ExistentialTraitRef throughout codegen

96bea7a

introduce ty::Value

2301f3e

Co-authored-by: FedericoBruzzone <federico.bruzzone.i@gmail.com>

Implement MIR, CTFE, and codegen for unsafe binders

83ab12f

Enforce unsafe binders must be Copy (for now)

6c0f4bb

Rename tcx.ensure() to tcx.ensure_ok()

89abc19

Sync from rust 854f225

77009e9

Rustup to rustc 1.86.0-nightly (854f225 2025-01-31)

3228d5e

bjorn3 added 5 commits February 7, 2025 14:14

Remove outdated fixme

4633398

Sync from rust 942db67

8bbe4a0

Rustup to rustc 1.86.0-nightly (942db67 2025-02-06)

6c4b94b

Fix rustc test suite

8332329

Merge commit '8332329f83d4ef34479fec67cc21b21246dca6b5' into sync_cg_…

cac271f

…clif-2025-02-07

matthiaskrgr mentioned this pull request Feb 8, 2025

Rollup of 8 pull requests #136734

Closed

matthiaskrgr mentioned this pull request Feb 8, 2025

Rollup of 7 pull requests #136740

Closed

bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 8, 2025

bors merged commit 73bf794 into rust-lang:master Feb 8, 2025
7 checks passed

rustbot added this to the 1.86.0 milestone Feb 8, 2025

bjorn3 deleted the sync_cg_clif-2025-02-07 branch February 8, 2025 21:38

bjorn3 mentioned this pull request Feb 8, 2025

Problem with Warning Related to x87 Flag rust-lang/rustc_codegen_cranelift#1559

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Subtree sync for rustc_codegen_cranelift #136715

Subtree sync for rustc_codegen_cranelift #136715

bjorn3 commented Feb 7, 2025

rustbot commented Feb 7, 2025

rustbot commented Feb 7, 2025

bjorn3 commented Feb 7, 2025

bors commented Feb 7, 2025

bors commented Feb 8, 2025

bors commented Feb 8, 2025

rust-timer commented Feb 8, 2025

Subtree sync for rustc_codegen_cranelift #136715

Subtree sync for rustc_codegen_cranelift #136715

Conversation

bjorn3 commented Feb 7, 2025

rustbot commented Feb 7, 2025

rustbot commented Feb 7, 2025

bjorn3 commented Feb 7, 2025

bors commented Feb 7, 2025

bors commented Feb 8, 2025

bors commented Feb 8, 2025

rust-timer commented Feb 8, 2025

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size