LLVM and SPIRV-LLVM-Translator pulldown (WW27 2025) #19233
Draft
+340,130
−151,150
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… MultiThreaded[Debug] on Windows (#139657) After llvm/llvm-project#81677, statically linking ASAN under Windows is no longer supported. Therefore, when using Clang built past llvm/llvm-project@53a81d4 to build LLVM / Clang with `-DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded[Debug] -DLLVM_USE_SANITIZER=Address`, a different set of dependent libraries must be linked. This is mentioned in the description of llvm/llvm-project#81677 and also in https://devblogs.microsoft.com/cppblog/msvc-address-sanitizer-one-dll-for-all-runtime-configurations/.
…#143415) Cf. https://discourse.llvm.org/t/mlir-dead-code-analysis/67568/10 Custom analysis passes will not work properly unless both DeadCodeAnalysis and SparseConstantPropagation are loaded to the DataFlowSolver. This is intended behavior, but surprising to many users as shown in the thread. In lieu of a longer-term fix (which I am not knowledgeable enough to implement myself, yet), this commit adds a helper function that loads these two analyses, as well as providing breadcrumbs for an explanation of the problem. The existing places in the codebase where these two analyses are loaded for the purpose of running other unrelated analyses are replaced by the use of the helper. --------- Co-authored-by: Jeremy Kun <[email protected]> Co-authored-by: Oleksandr "Alex" Zinenko <[email protected]>
Summary: I'll probably want to use this as a more generic utility in the future. This patch reworks it to make it a top level function. I also tried to decouple this from the OpenMP utilities to make that easier in the future. Instead, I just use `-march=native` functionality which is the same thing. Needed a small hack to skip the linker stage for checking if that works. This should still create the same output as far as I'm aware.
ArrayRef has a constructor that accepts std::nullopt. This constructor dates back to the days when we still had llvm::Optional. Since the use of std::nullopt outside the context of std::optional is kind of abuse and not intuitive to new comers, I would like to move away from the constructor and eventually remove it. This patch takes care of the mlir side of the migration, starting with straightforward places where I see ArrayRef or ValueRange nearby. Note that ValueRange has a constructor that forwards arguments to an ArrayRef constructor.
This PR adds an MCP (Model Context Protocol ) server to LLDB. For motivation and background, please refer to the corresponding RFC: https://discourse.llvm.org/t/rfc-adding-mcp-support-to-lldb/86798 I implemented this as a new kind of plugin. The idea is that we could support multiple protocol servers (e.g. if we want to support DAP from within LLDB). This also introduces a corresponding top-level command (`protocol-server`) with two subcommands to `start` and `stop` the server. ``` (lldb) protocol-server start MCP tcp://localhost:1234 MCP server started with connection listeners: connection://[::1]:1234, connection://[127.0.0.1]:1234 ``` The MCP sever supports one tool (`lldb_command`) which executes a command, but can easily be extended with more commands.
…LPV node use v2f64/v4f32 types When reducing v4f64/v8f32 non-lane crossing X86ISD::VPERMV nodes, we use X86ISD::VPERMILPV nodes for 128-bits, but these are only available for fp types. Fixes #145046
…… (#145014) …types usi… (#144676)" This reverts commit 68471d2. IntegralAP contains a union: union { uint64_t *Memory = nullptr; uint64_t Val; }; On 64bit systems, both Memory and Val have the same size. However, on 32 bit system, Val is 64bit and Memory only 32bit. Which means the default initializer for Memory will only zero half of Val. We fixed this by zero-initializing Val explicitly in the IntegralAP(unsigned BitWidth) constructor. See also the discussion in llvm/llvm-project#144246
Address NFC mismatches caused by running perf2bolt from under the wrapper script: https://lab.llvm.org/buildbot/#/builders/92/builds/20938 > <stdin>:2:64: note: possible intended match here > /home/worker/bolt-worker2/bolt-x86_64-ubuntu-nfc/build/bin/llvm-bolt.old: -spe is available only on AArch64. Test Plan: ninja check-bolt
`[]<list<int>>` actually produces `list<list<int>>`.
Allow the function definition line to match with and without attrbute set number. This fixes build break after PR144534: https://lab.llvm.org/buildbot/#/builders/157/builds/31331 Also move the test to the OpenMP subdirectory where it should have been from the beginning.
Adds support to MSan for `free_sized` and `free_aligned_sized` from C23. Other sanitizers will be handled with their own separate PRs. For llvm/llvm-project#144435 Signed-off-by: Justin King <[email protected]>
…s" (#145065) Reverts llvm/llvm-project#144880 Caused `TestObjCIvarsInBlocks.py` to fail on macOS CI.
Detected by CI after #143958.
…144157) See work detail: iree-org/iree#20920 Add support for f4E2M1FN in `arith.truncf` and `arith.extf` ops though a software emulation --------- Signed-off-by: Muzammiluddin Syed <[email protected]>
…16 is enabled (#144968) Fixes SWDEV-537014.
…79R0 (#144553) https://wg21.link/P3379R0 updated the value of __cpp_lib_constrained_equality, but we forgot to update it when we implemented the paper.
This patch disables unexpected_disabled_cpp17.verify.cpp under clang modules builds because it changes diagnostics criteria post #143423, causing the test to fail. This patch follows a similar style to 853059a. This was found when working on trying to land #144033.
… (#144799) isComplete previously meant different things for different conversion directions. Refactored bytes_processed to bytes_stored which now consistently increments on every push and decrements on pop making both directions more consistent with each other
…ins (#142480) Define the __dmr1024 type used to manipulate the new DMR registers introduced by the Dense Math Facility (DMF) on PowerPC, and add six Clang builtins that correspond to the integer outer-product accumulate to ACC PowerPC instructions: * __builtin_mma_dmxvi8gerx4 * __builtin_mma_pmdmxvi8gerx4 * __builtin_mma_dmxvi8gerx4pp * __builtin_mma_pmdmxvi8gerx4pp * __builtin_mma_dmxvi8gerx4spp * __builtin_mma_pmdmxvi8gerx4spp.
…a shuffle if the concat is free (#145043)
…undefined constant fixed-length vectors (#143837) This patch adds an off-by-default flag which, when enabled via `-mllvm -msan-poison-undef-vectors=true`, fixes a false negative in MSan (partially-undefined constant fixed-length vectors). It is currently off by default since, by fixing the false positive, code/tests that previously passed MSan may start failing. The default will be changed in a future patch. Prior to this patch, MSan computes that partially-undefined constant fixed-length vectors are fully initialized, which leads to false negatives; moreover, benign vector rewriting could theoretically flip MSan's shadow computation from initialized to uninitialized or vice-versa (*). `-msan-poison-undef-vectors=true` calculates the shadow precisely: for each element of the vector, the corresponding shadow is fully uninitialized if the element is undefined/poisoned, otherwise it is fully initialized. Updates the test from llvm/llvm-project#143823 (*) For example: ``` %x = insertelement <2 x i64> <i64 0, i64 poison>, i64 42, i64 0 %y = insertelement <2 x i64> <i64 poison, i64 poison>, i64 42, i64 0 ``` %x and %y are equivalent but, prior to this patch, MSan incorrectly computes the shadow of %x as <0, 0> rather than <0, -1>.
…#144097)
In Aya/Rust, BPF map definitions are nested in two nested types:
* A struct representing the map type (e.g., `HashMap`, `RingBuf`) that
provides methods for interacting with the map type (e.g. `HashMap::get`,
`RingBuf::reserve`).
* An `UnsafeCell`, which informs the Rust compiler that the type is
thread-safe and can be safely mutated even as a global variable. The
kernel guarantees map operation safety.
This leads to a type hierarchy like:
```rust
pub struct HashMap<K, V, const M: usize, const F: usize = 0>(
core::cell::UnsafeCell<HashMapDef<K, V, M, F>>,
);
const BPF_MAP_TYPE_HASH: usize = 1;
pub struct HashMapDef<K, V, const M: usize, const F: usize = 0> {
r#type: *const [i32; BPF_MAP_TYPE_HASH],
key: *const K,
value: *const V,
max_entries: *const [i32; M],
map_flags: *const [i32; F],
}
```
Then used in the BPF program code as a global variable:
```rust
#[link_section = ".maps"]
static HASH_MAP: HashMap<u32, u32, 1337> = HashMap::new();
```
Which is an equivalent of the following BPF map definition in C:
```c
#define BPF_MAP_TYPE_HASH 1
struct {
int (*type)[BPF_MAP_TYPE_HASH];
typeof(int) *key;
typeof(int) *value;
int (*max_entries)[1337];
} map_1 __attribute__((section(".maps")));
```
Accessing the actual map definition requires traversing:
```
HASH_MAP -> __0 -> value
```
Previously, the BPF backend only visited the pointee types of the
outermost struct, and didn’t descend into inner wrappers. This caused
issues when the key/value types were custom structs:
```rust
// Define custom structs for key and values.
pub struct MyKey(u32);
pub struct MyValue(u32);
#[link_section = ".maps"]
#[export_name = "HASH_MAP"]
pub static HASH_MAP: HashMap<MyKey, MyValue, 10> = HashMap::new();
```
These types weren’t fully visited and appeared in BTF as forward
declarations:
```
#30: <FWD> 'MyKey' kind:struct
#31: <FWD> 'MyValue' kind:struct
```
The fix is to enhance `visitMapDefType` to recursively visit inner
composite members. If a member is a composite type (likely a wrapper),
it is now also visited using `visitMapDefType`, ensuring that the
pointee types of the innermost stuct members, like `MyKey` and
`MyValue`, are fully resolved in BTF.
With this fix, the correct BTF entries are emitted:
```
#6: <STRUCT> 'MyKey' sz:4 n:1
#00 '__0' off:0 --> [7]
#7: <INT> 'u32' bits:32 off:0
#8: <PTR> --> [9]
#9: <STRUCT> 'MyValue' sz:4 n:1
#00 '__0' off:0 --> [7]
```
Fixes: #143361
CONFLICT (content): Merge conflict in clang/lib/Driver/ToolChains/Clang.cpp
…142687) Changes: * Decouple layout propagation from subgroup distribution and move it to an independent pass. * Refine layout assignment to handle control-flow ops correctly (scf.for, scf.while). * Refine test cases.
… (#144653) This allows us to better track the narrow type we need and to fix miscompiles if f16->f32 and bf16->f32 extends are mixed. Fixes #144651.
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
force-pushed
the
llvmspirv_pulldown
branch
from
2e4b0b4 to
36dd1da
Compare
mikolaj-pirog
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
mikolaj-pirog
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
had a problem deploying
to
WindowsCILock
GitHub Actions
Error
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
force-pushed
the
llvmspirv_pulldown
branch
from
36dd1da to
c011c4c
Compare
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
force-pushed
the
llvmspirv_pulldown
branch
from
c011c4c to
b52628e
Compare
mikolaj-pirog
had a problem deploying
to
WindowsCILock
GitHub Actions
Error
mikolaj-pirog
had a problem deploying
to
WindowsCILock
GitHub Actions
Error
mikolaj-pirog
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
mikolaj-pirog
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
mikolaj-pirog
force-pushed
the
llvmspirv_pulldown
branch
from
e46e614 to
31f4aef
Compare
mikolaj-pirog
requested a deployment
to
WindowsCILock
GitHub Actions
Queued
mikolaj-pirog
requested a deployment
to
WindowsCILock
GitHub Actions
Pending
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
LLVM: llvm/llvm-project@58987d2
SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@dcfd949