forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 77
merge main into amd-staging #1025
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
Merged
z1-cciauto
merged 48 commits into
amd-staging
from
amd/merge/upstream_merge_20260107070833
Jan 7, 2026
Merged
merge main into amd-staging #1025
z1-cciauto
merged 48 commits into
amd-staging
from
amd/merge/upstream_merge_20260107070833
Jan 7, 2026
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
Conservatively predicate sdiv/srem: - RHS may carry poison in masked‑off lanes. - RHS could be −1 while LHS has masked‑off lanes (risking INT_MIN/−1 overflow). We’ll relax this once we can prove non‑wrap/non‑poison conditions. Fixes llvm#170775.
Comments weren't very visually distinctive in HTML. They immediately proceeded the declaration header and didn't have spacing between them. To visually organize them, they now have a thin border around them. Different comment types are also now separated by a small gap. This also allows them to be easily changed in the future. Some extraneous `<div>` tags are also removed or merged.
…lvm#173965) To avoid false dependency.
Originally some `[[nodiscard]]` tests were implemented in `*/test/libcxx/diagnostics`. The Standard has a library `Diagnostics` and this folder should be reserved for it by convention. Most newer tests were added to their respective sub-folders. This patch moves around the already implemented `[[nodiscard]]` tests to their respective folders where they belong and standardizes the name to `nodiscard.verify.cpp` wherever possible. N.B. This refactors only tests, which were merged. The remaining (in-progress) ones will be moved in a future patch to reduce merge conflicts.
…me for RISCV vendor relocations (llvm#172811) Use getRISCVVendorRelocationTypeName to resolve RISCV vendor-specific relocation names (R_RISCV_CUSTOM192-255) when preceded by R_RISCV_VENDOR. This improves the output of llvm-readobj and llvm-objdump to show vendor-specific names like R_RISCV_QC_ABS20_U, R_RISCV_QC_E_BRANCH (QUALCOMM) and R_RISCV_NDS_BRANCH_10 (ANDES) instead of generic R_RISCV_CUSTOM* names. Per RISC-V psABI, R_RISCV_VENDOR must be placed immediately before its associated vendor-specific relocation, so the vendor symbol is consumed after one use. Unknown vendors fall back to R_RISCV_CUSTOM*.
…llvm#174677) The RISCVTargetMachine was still selecting RISCVELFTargetObjectFile, which was making llc crash when running the test at llvm/test/CodeGen/RISCV/riscv-macho.ll
…vm#174674) (llvm#174697) This reverts commit 0b2f3cf.
... so that `local:*;` will be lexed as three tokens instead of a single one in a version node. This is used by both version scripts and dynamic lists. Fix llvm#174363 In addition, clean up special code for space-separated `local :` and `global :`. This patch brings our lexer behavior closer to GNU ld. While GNU ld additionally rejects more characters like `~/+,=`, we don't implement this additional validation. Pull Request: llvm#174530
…lvm#172759) dropRedundantArguments was incorrectly indexing into forwardedOperands using the block argument index directly. This crashes when the block has produced operands (generated by the terminator, not forwarded from predecessors) because forwardedOperands doesn't include them. The fix checks isOperandProduced() to skip produced arguments and uses SuccessorOperands::operator[] which handles the offset correctly.
…named modules (llvm#174687) Declarations from named modules are used naturally. Thet are declarations in other TU. We don't need to record the information for updating them.
…ity analysis (llvm#174117)" This reverts commit 371fad2. The change only fixes the superficial assertion. The real problem is that bb.3 and bb.4 should not have been identified as joins of bb.5
Modify the C++ emitter to detect when an AddressOf op traces back to a const global. If it does, emit a C-style cast `(T*)(&...)` to strip the const qualification.
llvm#174704) Close llvm#174543 The root cause of the problem is that the recursion in the code pattern triggers infinite loop in the checking process for TU local exposure.
…/C++ (llvm#174707) For cvt and atomic `__builtin_amdgcn_cvt` builtins, using 'x' in the def to take _Float16 for HIP/C++ and half for OpenCL.
…4700) In this PR, I added a C API for each (upstream) MLIR type to retrieve its type name (for example, `IntegerType` -> `mlirIntegerTypeGetName()` -> `"builtin.integer"`), and exposed a corresponding `type_name` class attribute in the Python bindings (e.g., `IntegerType.type_name` -> `"builtin.integer"`). This can be used in various places to avoid hard-coded strings, such as eliminating the manual string in `irdl.base("!builtin.integer")`. Note that parts of this PR (mainly mechanical changes) were produced via GitHub Copilot and GPT-5.2. I have manually reviewed the changes and verified them with tests to ensure correctness.
…ns into main repository (llvm#166809) Allow the main llvm-project repository to contain the buildbot builder instructions, instead of storing them in llvm-zorg. The corresponding llvm-zorg PR is llvm/llvm-zorg#648. Using polly-x86_64-linux-test-suite as a proof-of-concept because that builder is currently offline, I am its maintainer, and is easier to build than an configuration supporting offload. Once the design has been decided, more builders can follow. Advantages are: * It is easier to make changes in the llvm-project repository. There are more reviewers than for the llvm-zorg repository. * Buildbot changes can be made in the same PR with changes that require updating the buildbot, e.g. changing the name of a CMake option. * Configuration changes take effect immeditately when landing; no buildbot master restart needed. * Some builders store a CMake cache file in the llvm-project repository for the reasons above. However, the number of changes that can be made with a CMake cache file alone are limited. Compared to AnnotatedBuilder, advantages are: * Reproducing a buildbot configuration locally made easy: just execute the script in-place. No llvm-zorg, local buildbot worker, or buildbot master needed. * Same for testing a change of a builder before landing it in llvm-zorg. Doing so with an AnnotatedBuilder requires two llvm-zorg checkouts: One for making the change of the builder script itself, which then is pushed to a private llvm-zorg branch on GitHub, and a second that is modified to fetch that branch instead of https://github.com/llvm/llvm-zorg/tree/main. * The AnnotatedBuilder scripts are located in the llvm-zorg repository and the buildbot-workers always checkout is always the top-of-trunk. This means that a buildbot configuration is split over three checkouts: * The checkout of llvm-project to be tested * The checkout of llvm-zorg by the buildbot-worker fetches; always the top-of-trunk, i.e may not match the revision of llvm-project that is executed (such as the CMake cache files located there), especially when using the "Force build" feature. * The checkout of llvm-zorg that the buildbot-master is running, which is updated only when the master is manually restarted. * The "Force Build" feature also allows for test-building any llvm-project PR. This is correctly handled by zorg's `addGetSourcecodeSteps`, but does not work with AnnotatedBuilders that checkout the llvm-project source on their own. The goal is to move as much as possible into the llvm-project repository such that there cannot be a mismatch between checkouts of different repositories. Ideally, the buildbot-master only needs to be updated+restarted for adding/removing workers, not for build configuration changes. --------- Co-authored-by: Jan Patrick Lehr <jp.lehr@gmail.com>
…() (llvm#171456) Reapply after additional fixes. ----- Disable implicit truncation in the ConstantInt constructor by default. This means that it needs to be passed a signed/unsigned (depending on the IsSigned flag) value matching the bit width. The intention is to prevent the recurring bug where people write something like `ConstantInt::get(Ty, -1)`, and this "works" until `Ty` is larger than 64-bit and then the value is incorrect due to missing type extension. This is the continuation of llvm#112670, which originally allowed implicit truncation in this constructor to reduce initial scope of the change.
…s in constraint-related nested scopes (llvm#173776) Fixes llvm#172814 --- This patch resolves an issue in which a lambda could be classified as always-dependent while traversing nested scopes, causing an assertion failure during capture handling. Changes in PR llvm#93206 expanded scope-based dependency handling in a way that could mark certain lambdas as always-dependent when no template-dependent context was present. This update refines the criteria for assigning `LambdaDependencyKind::LDK_AlwaysDependent` and applies it only after traversal reaches a distinct enclosing function scope with template-dependent parameters.
Several BTI-related functions are checking that a call MCInst has one non-annotation operand. This patch changes these checks to use MCPlus::getNumPrimeOperands, instead of getNumOperands. Testing: added annotations to existing gtests to serve as regression tests. These now also explicitly check getNumOperands and getNumPrimeOperands usage on the annotated MCInsts.
Don't duplicate the EnumEntry type in llvm-objdump. Spliced off from llvm#173868, where this is required to avoid the name collision.
- Pass plugins can use LLVM options, matching llvm#173287. - Pass plugins can run a hook before codegen, matching llvm#171872. - Pass plugins are now tested whenever they can be built, matching llvm#171998. Plugins currently don't work on AIX, tracked in llvm#172203.
We have special cases for `std::find` with `char` and `int` on most platforms, so the only other benchmark of or vector implementation is currently with `long long`, which is a rather big type. Adding `short` to the benchmarks allows us to more meaningfully compare the different implementations.
Delinearization has `isKnownLessThan(a, b)` function to check if `a < b` is known at compile time. To check the predicate, it calls `isKnownNegative(a - b)`. There are at least two issues with this approach: - It mixed up a signed interpretation with an unsigned one. - It doesn't consider overflow. This function includes some additional logic, which suffers from the same issues. This patch replace the call to `isKnownLessThan(a, b)` with `ScalarEvolution::isKnownPredicate(ICmpInst::ICMP_SLT, a, b)` and removes the former function entirely, since using it is risky and may lead to incorrect results. Resolve llvm#169812
…#170159) In VPlanPatternMatch.h I have changed the int_pred_ty code to look through broadcasts in order to catch more cases, i.e. multiplying by a splat of one, etc.
Previous checks were dead code. Now we share single `ALL-LABEL` checks by all run lines. Note: the regex is currently needed for `--match-full-lines` which is needed by itself because the previous versions of these tests suffered from false positives due to partial matching: llvm#143680.
Sink `fneg` operands of vector `fma` intrinsics to enable the `fmls` combine.
…ions in vector conversions (llvm#173498) Fixes llvm#173347 --- This patch resolves an assertion failure that occurs when instantiation-dependent expressions are constant-evaluated during vector conversions.
…0006) Fix lifetime safety analysis for pointer dereference operations by properly tracking origin flow. Added support in `FactsGenerator::VisitUnaryOperator()` to handle the dereference operator (`UO_Deref`). This change ensures that when a pointer is dereferenced, the origin of the pointer is properly propagated to the dereference expression.
We were checking whether the structured data value could be got as a boolean, not what value that boolean had. This meant we were incorrectly showing "yes" for everything.
Check if an scAddExpr expressions represents an URem, and if it does, use the divisor to limit the conservative range. https://alive2.llvm.org/ce/z/VPxe7C PR: llvm#174456
…ss check (llvm#173854) Add extra check to `CallAndMessageChecker` to find uninitialized non-const values passed through parameters. This check is used only at a specific list of C library functions which have non-const pointer parameters and the value should be initialized before the call.
Right now, some paths for `mlir:python` are missing, which means relevant people don’t always get notified. This PR adds those paths.
Fixes llvm#172893. In the issue reported above there, it appears that LLDB is hitting a 3s timeout as part of some CI tests; this patch attempts to fix the issue by replacing the 3s timeout with a 60s timeout, which should be suitably long for any CI job (lldb-dap itself will automatically time out after 30s, so this should not be hit unless the process hangs).
Testing LLDB-DAP vscode extension creates files in the .vscode-test folder ignore them.
…ions" (llvm#173135) Reverts llvm#158169 The improved AA precision for atomic store operations causes the DSE pass to optimize out the object variables.
…Int::get() (llvm#171456)" This reverts commit a83c894.
Collaborator
dpalermo
approved these changes
Jan 7, 2026
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.
No description provided.