| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
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
}])
}
])
```
|
|
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 5)
- Part of rust-lang/rust#134001
- Follow-up to rust-lang/rust#146673
---
This is another batch of LLVMDIBuilder binding migrations, replacing some our own LLVMRust bindings with bindings to upstream LLVM-C APIs.
Some of these are a little more complex than most of the previous migrations, because they split one LLVMRust binding into multiple LLVM bindings, but nothing too fancy.
This appears to be the last of the low-hanging fruit. As noted in https://github.com/rust-lang/rust/issues/134001#issuecomment-2524979268, the remaining bindings are difficult or impossible to migrate at present.
|
|
Co-authored-by: Nikita Popov <github@npopov.com>
|
|
|
|
This changed in upstream change a5569b4bd7f8.
@rustbot label llvm-main
|
|
Use `LLVMDisposeTargetMachine`
After bumping the minimum LLVM version to 20 (rust-lang/rust#145071), we no longer need to run any custom code when disposing of a TargetMachine, so we can just use the upstream LLVM-C function.
|
|
llvm: update remarks support on LLVM 22
LLVM change dfbd76bda01e removed separate remark support entirely, but
it turns out we can just drop the parameter and everything appears to
work fine.
Fixes rust-lang/rust#146912 as far as I can tell (the test passes.)
|
|
|
|
|
|
LLVM change dfbd76bda01e removed separate remark support entirely, but
it turns out we can just drop the parameter and everything appears to
work fine.
Fixes 146912 as far as I can tell (the test passes.)
@rustbot label llvm-main
|
|
[win] Use find-msvc-tools instead of cc to find the linker and rc on Windows
`find-msvc-tools` was factored out from `cc` to allow updating the use in `rustc_codegen_ssa` (finding the linker when running the Rust compiler) and `rustc_windows_rc` (finding the Windows Resource Compiler when running the Rust compiler) to be separate from the use in `rustc_llvm` (building LLVM as part of building the Rust compiler).
|
|
|
|
These should have been removed earlier, when we switched to the corresponding
LLVM-C bindings.
|
|
|
|
cg_llvm: Move target machine command-line quoting from C++ to Rust
When this code was introduced in rust-lang/rust#130446 and rust-lang/rust#131805, it was complicated by the need to maintain compatibility with earlier versions of LLVM.
Now that LLVM 20 is the baseline (rust-lang/rust#145071), we can do all of the quoting in pure Rust code, and pass two flat strings to LLVM to be used as-is.
---
In this PR, my priority has been to preserve the existing behaviour as much as possible, without worrying too much about what the behaviour *should* be. (Though I did avoid a leading space before the first argument.)
|
|
|
|
|
|
Signed-off-by: Karan Janthe <karanjanthe@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 3)
- Part of rust-lang/rust#134001
- Follow-up to rust-lang/rust#136375
- Follow-up to rust-lang/rust#136632
---
This is another batch of LLVMDIBuilder binding migrations, replacing some our own LLVMRust bindings with bindings to upstream LLVM-C APIs.
This PR migrates all of the bindings that were touched by rust-lang/rust#136632, plus `LLVMDIBuilderCreateStructType`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#139593 (add sitemap to rust docs)
- rust-lang/rust#145819 (Port limit attributes to the new attribute parsing infrastructure)
- rust-lang/rust#146025 (compiler: Include span of too huge array with `-Cdebuginfo=2`)
- rust-lang/rust#146184 (In the rustc_llvm build script, don't consider arm64* to be 32-bit)
- rust-lang/rust#146195 (fix partial urlencoded link support)
- rust-lang/rust#146300 (Implement `Sum` and `Product` for `f16` and `f128`.)
- rust-lang/rust#146314 (mark `format_args_nl!` as `#[doc(hidden)]`)
- rust-lang/rust#146324 (const-eval: disable pointer fragment support)
- rust-lang/rust#146326 (simplify the declaration of the legacy integer modules (`std::u32` etc.))
- rust-lang/rust#146339 (Update books)
- rust-lang/rust#146343 (Weakly export `platform_version` symbols)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
In the rustc_llvm build script, don't consider arm64* to be 32-bit
The build script for `rustc_llvm` needs to detect 32-bit targets so that it links against `libatomics`. To do this, it matches the target architecture against `arm`, unfortunately incorrectly matches Arm64EC, Arm64E, etc.
This change adds a check that the target arch doesn't match `arm64`.
|
|
compiler: Add Windows resources to rustc-main and rustc_driver
Adds Windows resources with the rust version information to rustc-main.exe and rustc_driver.dll
Invokes `rc.exe` directly, rather than using one of the crates from the ecosystem to avoid adding dependencies.
A new internal `rustc_windows_rc` crate has the common build script machinery for locating `rc.exe` and constructing the resource script
|
|
Misc LTO cleanups
Follow up to https://github.com/rust-lang/rust/pull/145955.
* Remove want_summary argument from `prepare_thin`.
Since https://github.com/rust-lang/rust/pull/133250 ThinLTO summary writing is instead done by `llvm_optimize`.
* Two minor cleanups
|
|
It is always false nowadays. ThinLTO summary writing is instead done by
llvm_optimize.
|
|
definitively excluded
|
|
Adds Windows resources with the rust version information to rustc-main.exe and rustc_driver.dll
Sets the product description to "Rust Compiler" or "Rust Compiler (channel)" for non-stable channels
|
|
|
|
This was done in #145740 and #145947. It is causing problems for people
using r-a on anything that uses the rustc-dev rustup package, e.g. Miri,
clippy.
This repository has lots of submodules and subtrees and various
different projects are carved out of pieces of it. It seems like
`[workspace.dependencies]` will just be more trouble than it's worth.
|
|
|
|
Add more to the `[workspace.dependencies]` section in the top-level `Cargo.toml`
Following on from rust-lang/rust#145740.
r? `@Kobzol`
|
|
All other sanitizer symbols are handled in prepare_lto already.
|
