Skip to content

LLVM and SPIRV-LLVM-Translator pulldown (WW27 2025) #19233

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

Draft
wants to merge 2,143 commits into
base: sycl
Choose a base branch
from
Draft

Conversation

iclsrc
Copy link
Contributor

@iclsrc iclsrc commented Jul 1, 2025

HemangGadhavi and others added 30 commits June 20, 2025 20:18
This PR is in reference to porting LLDB on AIX.
Link to discussions on llvm discourse and github:

1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. llvm/llvm-project#101657
The complete changes for porting are present in this draft PR:
llvm/llvm-project#102601

- Added skeleton for Registercontext file for AIX. (Later we will add
implementation respectively)
… targets (#145036)

We should only concat logic ops if at least one operand will freely
concatenate. We've now addressed the remaining regressions on AVX2
targets, but still have a number on AVX512 targets which can
aggressively use VPTERNLOG in many cases.
We can just always use `GetCXXObjectParameter` instead. We've only used
this attribute to set the object parameter name on ClangASTMetadata,
which doesn't seem like good enough justification to keep it around.

Depends on llvm/llvm-project#144879
ObjC methods include a +/- prefix to indicate if they are a class or
instance method. This information is valuable, and must be included in
the navigator generated by ExtractAPI.

rdar://150870936
… 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.
…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]>
…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.
@mikolaj-pirog
Copy link
Contributor

@mikolaj-pirog, I looked at the changes and most of them look okay to me, but I suggest we fix the build issues with --shared-libs instead of reverting PR #18918. Feel free to ask to @jchlanda or @sommerlukas for help if needed.

I was looking at this issue with @steffenlarsen -- it's affecting the sycl branch as well (only on --shared-libs build, see here for more details: #19291) and that's why I reverted it

@bader
Copy link
Contributor

bader commented Jul 3, 2025

@mikolaj-pirog, I looked at the changes and most of them look okay to me, but I suggest we fix the build issues with --shared-libs instead of reverting PR #18918. Feel free to ask to @jchlanda or @sommerlukas for help if needed.

I was looking at this issue with @steffenlarsen -- it's affecting the sycl branch as well (only on --shared-libs build, see here for more details: #19291) and that's why I reverted it

Then it's definitely should not be part of the pulldown. Just revert the patch in the sycl branch separately. It doesn't block the pulldown itself.
Pulling community commits to the sycl branch should not revert SYCL features.

@mikolaj-pirog
Copy link
Contributor

@mikolaj-pirog, I looked at the changes and most of them look okay to me, but I suggest we fix the build issues with --shared-libs instead of reverting PR #18918. Feel free to ask to @jchlanda or @sommerlukas for help if needed.

I was looking at this issue with @steffenlarsen -- it's affecting the sycl branch as well (only on --shared-libs build, see here for more details: #19291) and that's why I reverted it

Then it's definitely should not be part of the pulldown. Just revert the patch in the sycl branch separately. It doesn't block the pulldown itself. Pulling community commits to the sycl branch should not revert SYCL features.

Here's a pr with revert: #19304

@bader
Copy link
Contributor

bader commented Jul 4, 2025

@mikolaj-pirog, I looked at the changes and most of them look okay to me, but I suggest we fix the build issues with --shared-libs instead of reverting PR #18918. Feel free to ask to @jchlanda or @sommerlukas for help if needed.

I was looking at this issue with @steffenlarsen -- it's affecting the sycl branch as well (only on --shared-libs build, see here for more details: #19291) and that's why I reverted it

Then it's definitely should not be part of the pulldown. Just revert the patch in the sycl branch separately. It doesn't block the pulldown itself. Pulling community commits to the sycl branch should not revert SYCL features.

Here's a pr with revert: #19304

Thanks. Please, remove the revert from this pull request, resolve merge conflicts and fix the rest of the problems exposed by CI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disable-lint Skip linter check step and proceed with build jobs
Projects
None yet
Development

Successfully merging this pull request may close these issues.