Skip to content

GCC backend subtree update #143161

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 42 commits into from
Jun 29, 2025

Conversation

GuillaumeGomez
Copy link
Member

cc @antoyo

r? ghost

Noratrieb and others added 30 commits May 24, 2025 20:31
- Rename `USED` to `USED_COMPILER` to better reflect its behavior.
- Reorder some items to group the used and allocator flags together
- Renumber them without gaps
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.
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?
This avoids having to get the function signature.
Added support for testing the backend with abi-cafe
Skip needless calls to get_align in some cases.
Refactored the codebase to use Function instead of RValue where possible.
Remove unnecesary uses of the 'current_func' field, replacing it with  a call to function.
@rustbot
Copy link
Collaborator

rustbot commented Jun 28, 2025

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 28, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@antoyo
Copy link
Contributor

antoyo commented Jun 28, 2025

Are we doing something seriously wrong with our subtree syncs? This commit was already done in the subtree here.
I even frequently get conflicts between my own changes.
Any ideas what could cause all this?

@GuillaumeGomez
Copy link
Member Author

I think it's coming from a weird mix of git changes and my lack of knowledge on this part of cg_gcc.

@GuillaumeGomez
Copy link
Member Author

@bors delegate=antoyo

@bors
Copy link
Collaborator

bors commented Jun 28, 2025

✌️ @antoyo, you can now approve this pull request!

If @GuillaumeGomez told you to "r=me" after making some further change, please make that change, then do @bors r=@GuillaumeGomez

@antoyo
Copy link
Contributor

antoyo commented Jun 28, 2025

@bors r=GuillaumeGomez p=1

@bors
Copy link
Collaborator

bors commented Jun 28, 2025

📌 Commit 3dcbc1e has been approved by GuillaumeGomez

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 28, 2025
@bors
Copy link
Collaborator

bors commented Jun 29, 2025

⌛ Testing commit 3dcbc1e with merge dddd7ab...

@bors
Copy link
Collaborator

bors commented Jun 29, 2025

☀️ Test successful - checks-actions
Approved by: GuillaumeGomez
Pushing dddd7ab to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 29, 2025
@bors bors merged commit dddd7ab into rust-lang:master Jun 29, 2025
11 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jun 29, 2025
Copy link
Contributor

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 8141c22 (parent) -> dddd7ab (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard dddd7ab96229ea5f2ca96afcb5984a9831393a13 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. x86_64-apple-1: 7925.9s -> 6112.5s (-22.9%)
  2. x86_64-apple-2: 5668.2s -> 4627.2s (-18.4%)
  3. mingw-check-1: 1842.0s -> 1539.1s (-16.4%)
  4. mingw-check-2: 2120.0s -> 1827.2s (-13.8%)
  5. x86_64-rust-for-linux: 2946.9s -> 2545.2s (-13.6%)
  6. i686-gnu-2: 6174.1s -> 5412.1s (-12.3%)
  7. i686-gnu-nopt-1: 7980.9s -> 7012.4s (-12.1%)
  8. i686-gnu-1: 8210.4s -> 7330.8s (-10.7%)
  9. x86_64-gnu-tools: 3636.2s -> 3248.4s (-10.7%)
  10. x86_64-gnu-llvm-20-1: 3569.2s -> 3224.8s (-9.6%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (dddd7ab): 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 -1.3%, secondary 7.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Cycles

Results (secondary 2.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
2.8% [1.9%, 3.4%] 6
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

Results (secondary -0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Bootstrap: 693.957s -> 696.482s (0.36%)
Artifact size: 371.70 MiB -> 371.74 MiB (0.01%)

@GuillaumeGomez GuillaumeGomez deleted the subtree-update_cg_gcc_2025-06-28 branch June 29, 2025 09:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.