Skip to content
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

Rollup of 10 pull requests #134239

Closed

Conversation

compiler-errors
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

oli-obk and others added 22 commits December 10, 2024 08:07
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Co-authored-by: Ben Kimock <kimockb@gmail.com>
Bump to the latest wasi-sdk-25 release which brings in various wasi-libc
updates as well as LLVM 19 as the version used to compile wasi-libc.
Lexing precedes parsing, as you'd expect: `Lexer` creates a
`TokenStream` and `Parser` then parses that `TokenStream`.

But, in a horrendous violation of layering abstractions and common
sense, `Lexer` depends on `Parser`! The `Lexer::unclosed_delim_err`
method does some error recovery that relies on creating a `Parser` to do
some post-processing of the `TokenStream` that the `Lexer` just created.

This commit just removes `unclosed_delim_err`. This change removes
`Lexer`'s dependency on `Parser`, and also means that `lex_token_tree`'s
return value can have a more typical form.

The cost is slightly worse error messages in two obscure cases, as shown
in these tests:
- tests/ui/parser/brace-in-let-chain.rs: there is slightly less
  explanation in this case involving an extra `{`.
- tests/ui/parser/diff-markers/unclosed-delims{,-in-macro}.rs: the diff
  marker detection is no longer supported (because that detection is
  implemented in the parser).

In my opinion this cost is outweighed by the magnitude of the code
cleanup.
Autodiff Upstreaming - rustc_codegen_llvm changes

Now that the autodiff/Enzyme backend is merged, this is an upstream PR for the `rustc_codegen_llvm` changes.
It also includes small changes to three files under `compiler/rustc_ast`, which overlap with my frontend PR (rust-lang#129458).
Here I only include minimal definitions of structs and enums to be able to build this backend code.
The same goes for minimal changes to `compiler/rustc_codegen_ssa`, the majority of changes there will be in another PR, once either this or the frontend gets merged.

We currently have 68 files left to merge, 19 in the frontend PR, 21 (+3 from the frontend) in this PR, and then ~30 in the middle-end.

This PR is large because it includes two of my three large files (~800 loc each). I could also first only upstream enzyme_ffi.rs, but I think people might want to see some use of these bindings in the same PR?

To already highlight the things which reviewers might want to discuss:

1) `enzyme_ffi.rs`: I do have a fallback module to make sure that we don't link rustc against Enzyme when we build rustc without autodiff support.

2) `add_panic_msg_to_global` was a pain to write and I currently can't even use it. Enzyme writes gradients into shadow memory. Pass in one float scalar? We'll allocate and return an extra float telling you how this float affected the output. Pass in a slice of floats? We'll let you allocate the vector and pass in a mutable reference to a float slice, we'll then write the gradient into that slice. It should be at least as large as your original slice, so we check that and panic if not. Currently we panic silently, but I already generate a nicer panic message with this function. I just don't know how to print it to the user. yet. I discussed this with a few rustc devs and the best we could come up with (for now), was to look for mangled panic calls in the IR and pick one, which works surprisingly reliably. If someone knows a good way to clean this up and print the panic message I'm all in, otherwise I can remove the code that writes the nicer panic message and keep the silent panic, since it's enough for soundness. Especially since this PR is already a bit larger.

3) `SanitizeHWAddress`: When differentiating C++, Enzyme can use TBAA to "understand" enums/unions, but for Rust we don't have this information. LLVM might to speculative loads which (without TBAA) confuse Enzyme, so we disable those with this attribute. This attribute is only set during the first opt run before Enzyme differentiates code. We then remove it again once we are done with autodiff and run the opt pipeline a second time. Since enums are everywhere in Rust, support for them is crucial, but if this looks too cursed I can remove these ~100 lines and keep them in my fork for now, we can then discuss them separately to make this PR simpler?

4) Duplicated llvm-opt runs: Differentiating already optimized code (and being able to do additional optimizations on the fly, e.g. for GPU code) is _the_ reason why Enzyme is so fast, so the compile time is acceptable for autodiff users:  https://enzyme.mit.edu/talks/Publications/ (There are also algorithmic issues in Enzyme core which are more serious than running opt twice).

5) I assume that if we merge these minimal cg_ssa changes here already, I also need to fix the other backends (GCC and cliff) to have dummy implementations, correct?

6) *I'm happy to split this PR up further if reviewers have recommendations on how to.*

For the full implementation, see: rust-lang#129175

Tracking:

- rust-lang#124509
Fix powerpc64 big-endian FreeBSD ABI

Note that FreeBSD version bump may be reverted due to rust-lang#120869 (comment). We may want to wait to merge this until that discussion is complete.

Fixes rust-lang#120869 (comment)

> > PPC64 FreeBSD (ELFv1 and ELFv2, version 13.2)
>
> It seems odd that ELFv1 and 13.N coexist.
>
> https://www.freebsd.org/releases/13.0R/relnotes/
>
> > powerpc64 switched to ELFv2 ABI at the same time it switched to LLVM. This brings us to a parity with modern Linux distributions. This also makes the binaries from previous FreeBSD versions incompatible with 13.0-RELEASE. Kernel still supports ELFv1, so jails and chroots using older FreeBSD versions are still compatible. [e4399d169acc](https://cgit.freebsd.org/src/commit/?id=e4399d169acc)
>
> Well, it is also odd that this target claims ELFv2 support since our ABI code does not use ELFv2 on this target.
>
> https://github.com/rust-lang/rust/blob/be01dabfefd2daa4574b974f571c7852085d60cb/compiler/rustc_target/src/callconv/powerpc64.rs#L102-L111

`@rustbot` label +O-PowerPC +O-freebsd
Clarify how to use `black_box()`

Closes rust-lang#133923.

r? libs
^ (I think that's the right group, this is my first time!)

This PR adds further clarification on the [`black_box()`](https://doc.rust-lang.org/stable/std/hint/fn.black_box.html) documentation. Specifically, it teaches _how_ to use it, instead of just _when_ to use it.

I tried my best to make it clear and accurate, but a lot of my information is sourced from rust-lang/rust-clippy#12707 and [manually inspecting assembly](https://godbolt.org/). Please tell me if I got anything wrong!
Try to evaluate constants in legacy mangling

Best reviewed commit by commit.

It seems kind of odd to treat literals differently from unevaluated free constants. So let's evaluate those constants and only fall back to `_` rendering if that fails to result in an integral constant
…=compiler-errors

Remove `Lexer`'s dependency on `Parser`.

Lexing precedes parsing, as you'd expect: `Lexer` creates a `TokenStream` and `Parser` then parses that `TokenStream`.

But, in a horrendous violation of layering abstractions and common sense, `Lexer` depends on `Parser`! The `Lexer::unclosed_delim_err` method does some error recovery that relies on creating a `Parser` to do some post-processing of the `TokenStream` that the `Lexer` just created.

This commit just removes `unclosed_delim_err`. This change removes `Lexer`'s dependency on `Parser`, and also means that `lex_token_tree`'s return value can have a more typical form.

The cost is slightly worse error messages in two obscure cases, as shown in these tests:
- tests/ui/parser/brace-in-let-chain.rs: there is slightly less explanation in this case involving an extra `{`.
- tests/ui/parser/diff-markers/unclosed-delims{,-in-macro}.rs: the diff marker detection is no longer supported (because that detection is implemented in the parser).

In my opinion this cost is outweighed by the magnitude of the code cleanup.

r? ``@chenyukang``
…-errors

coverage: Tidy up creation of covmap and covfun records

This is a small follow-up to rust-lang#134163 that mostly just inlines and renames some variables, and adds a few comments.

It also slightly defers the creation of the LLVM value that holds the filename table, to just before the value is needed.
…youxu

validate `--skip` and `--exclude` paths

Fixes rust-lang#134198

cc ``@ChrisDenton``
…er-errors

On Neutrino QNX, reduce the need to set archiver via environment variables

This adds support for automatically selecting the correct `ar` tool when compiling for Neutrino QNX.
Once rust-lang/cc-rs#1319 is merged and a new cc version is integrated, all environment variables of the [Neutrino documentation](https://github.com/rust-lang/rust/blob/stable/src/doc/rustc/src/platform-support/nto-qnx.md) can be removed.

CC: `@jonathanpallant` `@japaric` `@gh-tr` `@AkhilTThomas`
Update wasi-sdk used to build WASI targets

Bump to the latest wasi-sdk-25 release which brings in various wasi-libc updates as well as LLVM 19 as the version used to compile wasi-libc.

- https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-24
- https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-25
…aethlin

Fix typos in docs on provenance

This is related to [strict provenance](rust-lang#95228).

Added a couple cross-refs, also replaced

> Create a pointer without provenance from just an address (see [`ptr::dangling`]).

with

> Create a pointer without provenance from just an address (see [`without_provenance`]).

as this method actually takes an address.
@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Dec 13, 2024
@compiler-errors
Copy link
Member Author

@bors r+ rollup=never p=10

@bors
Copy link
Contributor

bors commented Dec 13, 2024

📌 Commit 8a50b23 has been approved by compiler-errors

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 Dec 13, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 13, 2024
…mpiler-errors

Rollup of 10 pull requests

Successful merges:

 - rust-lang#130060 (Autodiff Upstreaming - rustc_codegen_llvm changes)
 - rust-lang#132150 (Fix powerpc64 big-endian FreeBSD ABI)
 - rust-lang#133942 (Clarify how to use `black_box()`)
 - rust-lang#134081 (Try to evaluate constants in legacy mangling)
 - rust-lang#134192 (Remove `Lexer`'s dependency on `Parser`.)
 - rust-lang#134208 (coverage: Tidy up creation of covmap and covfun records)
 - rust-lang#134209 (validate `--skip` and `--exclude` paths)
 - rust-lang#134211 (On Neutrino QNX, reduce the need to set archiver via environment variables)
 - rust-lang#134227 (Update wasi-sdk used to build WASI targets)
 - rust-lang#134229 (Fix typos in docs on provenance)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors
Copy link
Contributor

bors commented Dec 13, 2024

⌛ Testing commit 8a50b23 with merge b95001c...

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-mingw-2 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@bors
Copy link
Contributor

bors commented Dec 13, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 13, 2024
@compiler-errors compiler-errors deleted the rollup-j5r5ey7 branch December 13, 2024 04:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.