https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=perf-tmp 2025-09-30T19:53:33+00:00 2025-09-30T19:53:33+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-09-30T19:53:33+00:00 urn:sha1:5a4713d8ea9af8185e61a93a97c4f63020f4fc06 Add a dummy codegen backend This allows building a rustc capable of running the frontend without any backend present. While this may not seem all that useful, it allows running the frontend of rustc to report errors or running miri to interpret a program without any backend present. This is useful when you are trying to say run miri in the browser as upstream LLVM can't be compiled for wasm yet. Or to run rustc itself in miri like I did a while ago and caught some UB. 2025-09-29T15:06:55+00:00 bors bors@rust-lang.org 2025-09-29T15:06:55+00:00 urn:sha1:dc2c3564d273cf8ccce32dc4f47eaa27063bceb9 debuginfo: add an unstable flag to write split DWARF to an explicit directory Bazel requires knowledge of outputs from actions at analysis time, including file or directory name. In order to work around the lack of predictable output name for dwo files, we group the dwo files in a subdirectory of --out-dir as a post-processing step before returning control to bazel. Unfortunately some debugging workflows rely on directly opening the dwo file rather than loading the merged dwp file, and our trick of moving the files breaks those users. We can't just hardlink the file or copy it, because with remote build execution we wouldn't end up with the un-moved file copied back to the developer's workstation. As a fix, we add this unstable flag that causes dwo files to be written to a build-system-controllable location, which then lets bazel hoover up the dwo files, but the objects also have the correct path for the dwo files. r? `@davidtwco` 2025-09-29T14:34:58+00:00 bjorn3 17426603+bjorn3@users.noreply.github.com 2024-11-12T18:31:54+00:00 urn:sha1:adf9cbd69ccd9c1e973fe179fbf3e53b23b4a5ae This allows building a rustc capable of running the frontend without any backend present. While this may not seem all that useful, it allows running the frontend of rustc to report errors or running miri to interpret a program without any backend present. This is useful when you are trying to say run miri in the browser as upstream LLVM can't be compiled for wasm yet. Or to run rustc itself in miri like I did a while ago and caught some UB. 2025-09-29T01:56:42+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-09-29T01:56:42+00:00 urn:sha1:01b172ef33ff2aaaa11ed36cfed7cceedc214423 Do not compute optimized MIR if code does not type-check. Since https://github.com/rust-lang/rust/pull/128612, we compute optimized MIR when `-Zvalidate-mir` is present. This is done as part of required analyses, even if type-checking fails. This causes ICEs, as most of the mir-opt pipeline expects well-formed code. Fixes rust-lang/rust#129095 Fixes rust-lang/rust#134174 Fixes rust-lang/rust#134654 Fixes rust-lang/rust#135570 Fixes rust-lang/rust#136381 Fixes rust-lang/rust#137468 Fixes rust-lang/rust#144491 Fixes rust-lang/rust#147011 This does not fix issue rust-lang/rust#137190, as it ICEs without `-Zvalidate-mir`. r? ``@compiler-errors`` 2025-09-28T16:13:11+00:00 Matthias Krüger 476013+matthiaskrgr@users.noreply.github.com 2025-09-28T16:13:11+00:00 urn:sha1:c29fb2e57ed0578c9051cc9314b0225f847de710 TypeTree support in autodiff # TypeTrees for Autodiff ## What are TypeTrees? Memory layout descriptors for Enzyme. Tell Enzyme exactly how types are structured in memory so it can compute derivatives efficiently. ## Structure ```rust TypeTree(Vec<Type>) Type { offset: isize, // byte offset (-1 = everywhere) size: usize, // size in bytes kind: Kind, // Float, Integer, Pointer, etc. child: TypeTree // nested structure } ``` ## Example: `fn compute(x: &f32, data: &[f32]) -> f32` **Input 0: `x: &f32`** ```rust TypeTree(vec![Type { offset: -1, size: 8, kind: Pointer, child: TypeTree(vec![Type { offset: -1, size: 4, kind: Float, child: TypeTree::new() }]) }]) ``` **Input 1: `data: &[f32]`** ```rust TypeTree(vec![Type { offset: -1, size: 8, kind: Pointer, child: TypeTree(vec![Type { offset: -1, size: 4, kind: Float, // -1 = all elements child: TypeTree::new() }]) }]) ``` **Output: `f32`** ```rust TypeTree(vec![Type { offset: -1, size: 4, kind: Float, child: TypeTree::new() }]) ``` ## Why Needed? - Enzyme can't deduce complex type layouts from LLVM IR - Prevents slow memory pattern analysis - Enables correct derivative computation for nested structures - Tells Enzyme which bytes are differentiable vs metadata ## What Enzyme Does With This Information: Without TypeTrees (current state): ```llvm ; Enzyme sees generic LLVM IR: define float ``@distance(ptr*`` %p1, ptr* %p2) { ; Has to guess what these pointers point to ; Slow analysis of all memory operations ; May miss optimization opportunities } ``` With TypeTrees (our implementation): ```llvm define "enzyme_type"="{[]:Float@float}" float ``@distance(`` ptr "enzyme_type"="{[]:Pointer}" %p1, ptr "enzyme_type"="{[]:Pointer}" %p2 ) { ; Enzyme knows exact type layout ; Can generate efficient derivative code directly } ``` # TypeTrees - Offset and -1 Explained ## Type Structure ```rust Type { offset: isize, // WHERE this type starts size: usize, // HOW BIG this type is kind: Kind, // WHAT KIND of data (Float, Int, Pointer) child: TypeTree // WHAT'S INSIDE (for pointers/containers) } ``` ## Offset Values ### Regular Offset (0, 4, 8, etc.) **Specific byte position within a structure** ```rust struct Point { x: f32, // offset 0, size 4 y: f32, // offset 4, size 4 id: i32, // offset 8, size 4 } ``` TypeTree for `&Point` (internal representation): ```rust TypeTree(vec![ Type { offset: 0, size: 4, kind: Float }, // x at byte 0 Type { offset: 4, size: 4, kind: Float }, // y at byte 4 Type { offset: 8, size: 4, kind: Integer } // id at byte 8 ]) ``` Generates LLVM: ```llvm "enzyme_type"="{[]:Float@float}" ``` ### Offset -1 (Special: "Everywhere") **Means "this pattern repeats for ALL elements"** #### Example 1: Array `[f32; 100]` ```rust TypeTree(vec![Type { offset: -1, // ALL positions size: 4, // each f32 is 4 bytes kind: Float, // every element is float }]) ``` Instead of listing 100 separate Types with offsets `0,4,8,12...396` #### Example 2: Slice `&[i32]` ```rust // Pointer to slice data TypeTree(vec![Type { offset: -1, size: 8, kind: Pointer, child: TypeTree(vec![Type { offset: -1, // ALL slice elements size: 4, // each i32 is 4 bytes kind: Integer }]) }]) ``` #### Example 3: Mixed Structure ```rust struct Container { header: i64, // offset 0 data: [f32; 1000], // offset 8, but elements use -1 } ``` ```rust TypeTree(vec![ Type { offset: 0, size: 8, kind: Integer }, // header Type { offset: 8, size: 4000, kind: Pointer, child: TypeTree(vec![Type { offset: -1, size: 4, kind: Float // ALL array elements }]) } ]) ``` 2025-09-28T15:59:21+00:00 Camille Gillot gillot.camille@gmail.com 2025-09-27T13:28:25+00:00 urn:sha1:7a7cb05f11a81e261e22f9ae291755b6343f7095 2025-09-26T17:34:40+00:00 Augie Fackler augie@google.com 2025-03-07T03:10:42+00:00 urn:sha1:77c6acc74ecd44ba7eb5a73c934dffdff7340133 Bazel requires knowledge of outputs from actions at analysis time, including file or directory name. In order to work around the lack of predictable output name for dwo files, we group the dwo files in a subdirectory of --out-dir as a post-processing step before returning control to bazel. Unfortunately some debugging workflows rely on directly opening the dwo file rather than loading the merged dwp file, and our trick of moving the files breaks those users. We can't just hardlink the file or copy it, because with remote build execution we wouldn't end up with the un-moved file copied back to the developer's workstation. As a fix, we add this unstable flag that causes dwo files to be written to a build-system-controllable location, which then lets bazel hoover up the dwo files, but the objects also have the correct path for the dwo files. 2025-09-25T10:31:58+00:00 Stuart Cook Zalathar@users.noreply.github.com 2025-09-25T10:31:58+00:00 urn:sha1:62aa0ae29f483d685745a4795c9cc65e2a1171e6 Small string formatting cleanup This PR is mostly useless. I was going through this file, saw that and corrected it. That's pretty much it. Feel free to close it if it's a bother. 2025-09-24T21:47:13+00:00 Guillaume Gomez guillaume1.gomez@gmail.com 2025-09-24T21:47:05+00:00 urn:sha1:aa75d340353dd07bf347978360a9566831128e35 2025-09-24T13:04:19+00:00 bors bors@rust-lang.org 2025-09-24T13:04:19+00:00 urn:sha1:15283f6fe95e5b604273d13a428bab5fc0788f5a Extends AArch64 branch protection support to include GCS Extends existing support for AArch64 branch protection to include support for [Guarded Control Stacks](https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-2022#guarded-control-stack-gcs:~:text=Extraction%20or%20tracking.-,Guarded%20Control%20Stack%20(GCS),-With%20the%202022).