)]}'
{
  "commit": "f0af5f5777738560ee7e00a6101107e829ae4c29",
  "tree": "5aa7bfa3e62642585c7f4f95bf73e08671eb871b",
  "parents": [
    "2b77fc4702f566c32e7f6095752605651053a5ce",
    "11f350da386e3fa51c106c09db1cf4d637754a9c"
  ],
  "author": {
    "name": "Jonathan Brouwer",
    "email": "jonathantbrouwer@gmail.com",
    "time": "Mon Apr 13 20:19:54 2026 +0200"
  },
  "committer": {
    "name": "GitHub",
    "email": "noreply@github.com",
    "time": "Mon Apr 13 20:19:54 2026 +0200"
  },
  "message": "Rollup merge of #140763 - sayantn:test-amx, r\u003ddianqk\n\nChange codegen of LLVM intrinsics to be name-based, and add llvm linkage support for `bf16(xN)` and `i1xN`\n\n*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/140763)*\n\nThis PR changes how LLVM intrinsics are codegen\n\n# Explanation of the changes\n\n## Current procedure\n\nThis is the same for all functions, LLVM intrinsics are _not_ treated specially\n - We get the LLVM Type of a function simply using the argument types. For example, the following function\n   ```rust\n   #[link_name \u003d \"llvm.sqrt.f32\"]\n   fn sqrtf32(a: f32) -\u003e f32;\n   ```\n   will have LLVM type simply `f32 (f32)` due to the Rust signature\n\n### Pros\n\n - Simpler to implement, no extra complexity involved due to LLVM intrinsics\n\n### Cons\n\n - LLVM intrinsics have a well-defined signature, completely defined by their name (and if it is overloaded, the type parameters). So, this process of converting Rust signatures to LLVM signatures may not work, for example the following code generates LLVM IR without any problem\n   ```rust\n   #[link_name \u003d \"llvm.sqrt.f32\"]\n   fn sqrtf32(a: i32) -\u003e f32;\n   ```\n   but the generated LLVM IR is invalid, because it has wrong signature for the intrinsic ([Godbolt](https://godbolt.org/z/6ff9hrcd5), adding `-Zverify-llvm-ir` to it will fail compilation). I would expect this code to not compile at all instead of generating invalid IR.\n - LLVM intrinsics that have types in their signature that can\u0027t be accessed from Rust (notable examples are the AMX intrinsics that have the `x86amx` type, and (almost) all intrinsics that have vectors of `i1` types) can\u0027t be linked to at all. This is a (major?) roadblock in the AMX and AVX512 support in stdarch.\n - If code uses an non-existing LLVM intrinsic, even `-Zverify-llvm-ir` won\u0027t complain. Eventually it will error out due to the non-existing function (courtesy of the linker). I don\u0027t think this is a behavior we want.\n\n## What this PR does\n\n - When linking to **non-overloaded** intrinsics, we use the function `LLVMIntrinsicGetType` to directly get the function type of the intrinsic from LLVM.\n - We then use this LLVM definition to _verify_ the Rust signature, and emit a proper error if it doesn\u0027t match, instead of silently emitting invalid IR.\n - Lint if linking to deprecated or invalid LLVM intrinsics\n\n\u003e [!NOTE]\n\u003e This PR only focuses on non-overloaded intrinsics, overloaded can be done in a future PR\n\nRegardless, the undermentioned functionalities work for **all** intrinsics\n\n - If we can\u0027t find the intrinsic, we check if it has been `AutoUpgrade`d by LLVM. If not, that means it is an invalid intrinsic, and we error out.\n - Don\u0027t allow intrinsics from other archs to be declared, e.g. error out if an AArch64 intrinsic is declared when we are compiling for x86\n\n### Pros\n\n - It is now not possible (or at least, it would require _significantly_ more leaps and bounds) to introduce invalid IR using **non-overloaded** LLVM intrinsics.\n - As we are now doing the matching of Rust signatures to LLVM intrinsics ourselves, we can now add bypasses to enable linking to such non-Rust types (e.g. matching 8192-bit vectors to `x86amx` and injecting `llvm.x86.cast.vector.to.tile` and `llvm.x86.cast.tile.to.vector`s in callsite)\n\n\u003e [!NOTE]\n\u003e I don\u0027t intend for these bypasses to be permanent. A better approach will be introducing a `bf16` type in Rust, and allowing `repr(simd)` with `bool`s to get Rust-native `i1xN`s. These are meant to be short-time, as I mentioned, \"bypass\"es. They shouldn\u0027t cause any major breakage even if removed, as `link_llvm_intrinsics` is perma-unstable.\n\n   This PR adds bypasses for `bf16` (via `i16`), `bf16xN` (via `i16xN`) and `i1xN` (via `iM`, where `M` is the smallest power of 2  s.t. `M \u003e\u003d N`, unless `N \u003c\u003d 4`, where we use `M \u003d 8`). This will unblock AVX512-VP2INTERSECT and a lot of bf16 intrinsics in stdarch. This PR also automatically destructures structs if the types don\u0027t exactly match (this is required for us to start emitting hard errors on mismmatches).\n\n### Cons\n\n - This only works for non-overloaded intrinsics (at least for now). Improving this to work with overloaded intrinsics too will involve significantly more work.\n\n# Possible ways to extend this to overloaded intrinsics (future)\n\n## Parse the mangled intrinsic name to get the type parameters\n\nLLVM has a stable mangling of intrinsic names with type parameters (in `LLVMIntrinsicCopyOverloadedName2`), so we can parse the name to get the type parameters, and then just do the same thing.\n\n### Pros\n - For _most_ intrinsics, this will work perfectly, and is a easy way to do this.\n\n### Cons\n - The LLVM mangling is not perfectly reversible. When we have `TargetExt` types or identified structs, their name is a part of the mangling, making it impossible to reverse. Even more complexities arise when there are unnamed identified structs, as LLVM adds more mangling to the names.\n - @nikic\u0027s work on LLVM intrinsics will remove the name mangling, making this approach impossible\n\n## Use the `IITDescriptor` table and the Rust function signature\n\nWe can use the base name to get the `IITDescriptor`s of the corresponding intrinsic, and then manually implement the _matching_ logic based on the Rust signature.\n\n### Pros\n\n - Doesn\u0027t have the above mentioned limitation of the parsing approach, has correct behavior even when there are identified structs and `TargetExt` types. Also, fun fact, Rust exports all struct types as literal structs (unless it is emitting LLVM IR, then it always uses named identified structs, with mangled names)\n\n### Cons\n\n - **Doesn\u0027t** actually use the type parameters in the name, only uses the base name and the Rust signature to get the llvm signature (although we _can_ check that it is the correct name). It means there would be no way to (for example) link against `llvm.sqrt.bf16` until we have `bf16` types in Rust. Because if we are using `u16`s (or any other type) as `bf16`s, then the matcher will deduce that the signature is `u16 (u16)` not `bf16 (bf16)` (which would lead to an error because `u16` is not a valid type parameter for `llvm.sqrt`), even though the intended type parameter is specified in the name.\n - Much more complex, and hard to maintain as LLVM gets new `IITDescriptorKind`s\n\nThese 2 approaches might give different results for same function. Let\u0027s take\n```rust\n#[link_name \u003d \"llvm.is.constant.bf16\"]\nfn foo(a: u16) -\u003e bool\n```\nThe name-based approach will decide that the type parameter is `bf16`, and the LLVM signature is `i1 (bf16)` and will inject some bitcasts at callsite.\nThe `IITDescriptor`-based approach will decide that the LLVM signature is `i1 (u16)`, and will see that the name given doesn\u0027t match the expected name (`llvm.is.constant.u16`), and will error out.\n\nReviews are welcome, as this is my first time _actually_ contributing to `rustc`\n\n@rustbot label T-compiler A-codegen A-LLVM\nr? codegen\n",
  "tree_diff": []
}