merge main into amd-staging #519
Merged
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
Summary: This was a lot of code that was only used for upstream LLVM builds of AMDGPU offloading. We have a generic and fast `malloc` in `libc` now so just use that. Simplifies code, can be added back if we start providing alternate forms but I don't think there's a single use-case that would justify it yet.
llvm#166633) This change removes empty `acc.kernel_environment` operations during canonicalization. This could happen when the acc compute construct inside the `acc.kernel_environment` is optimized away in cases such as when only private variables are being written to in the loop. In cases of empty `acc.kernel_environment` ops with waitOperands, we still remove the empty `acc.kernel_environment`, but also create an `acc.wait` operation to take those wait operands to preserve synchronization behavior.
Those have only a few uses.
This intrinsic emits a BFD_RELOC_NONE relocation at the point of call, which allows optimizations and languages to explicitly pull in symbols from static libraries without there being any code or data that has an effectual relocation against such a symbol. See issue llvm#146159 for context.
The template arguments specify the *target* type, not the *source* type.
…Location (llvm#166588) `writeBareSourceLocation` is always called on either `Expanded` or `Spelling` location, in any on those cases the `SM.getSpellingLineNumber(Loc) == SM.getExpansionLineNumber(Loc) == SM.getLineNumber(Loc)`.
55436ae broke this on Windows as we only use Python 3.9 there, but the construct is only supported from 3.10 onwards. Use the old Optional type to ensure compatibility.
…g GEP type (llvm#166200) This pr lets the `dxil-data-scalarization` account for a GEP with a source type that is a sub-type of the pointer operand type. The pass is updated so that the replaced GEP introduces zero indices such that the result type remains the same (with the vector -> array transform). Please see resolved issue for an annotated example. Resolves: llvm#165473
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [actions/download-artifact](https://redirect.github.com/actions/download-artifact) | action | major | `v5.0.0` -> `v6.0.0` | | [actions/upload-artifact](https://redirect.github.com/actions/upload-artifact) | action | major | `v4.6.2` -> `v5.0.0` | | [actions/upload-artifact](https://redirect.github.com/actions/upload-artifact) | action | major | `4.6.2` -> `5.0.0` |
…6764) Fixes llvm#161223 Procedure pointers in Fortran were generating incorrect debug type information, showing as 'integer' in GDB instead of the actual procedure signature.
…lvm#166211) There can only be meaningful aliasing between the memory accesses of different instructions if at least one of the accesses modifies memory. This check is applied at the instruction-level earlier in the method. This change merely extends the check on a per-MMO basis. This affects a SystemZ test because PFD instructions are both mayLoad and mayStore but may carry a load-only MMO which is now no longer treated as aliasing loads. The PFD instructions are from llvm.prefetch generated by loop-data-prefetch.
…#165852) Fixed `getORCRuntimePath` function to respect `getCompilerRTPath` and `getRuntimePath`
…lvm#166467) We are skipping four zero's at a time when validating code padding in case that the next zero would be part of an instruction or constant island, and for functions that have large amount of padding (like due to hugify), this could be very slow. We now change the validation to skip as many as possible but still need to be 4's exact multiple number of zero's. No valid instruction has encoding as 0x00000000 and even if we stumble into some constant island, the API `BinaryFunction::isInConstantIsland()` has been made to find the size between the asked address and the end of island (llvm#164037), so this should be safe.
`Op0` should always be checked before `Op1`. Otherwise it may not work as expected when `Op1` contains `m_Deferred`.
…vm#152737) This PR adds hardware-measured latencies for all instructions defined in Section 14 of the RVV specification: "Vector Reduction Operations" to the SpacemiT-X60 scheduling model. --------- Signed-off-by: Mikhail R. Gadelha <mikhail@igalia.com>
Reland reverted PR [llvm#164704](llvm#164704). Overflow is checked in the strong SIV test in DA on calculation of the product of `UpperBound` and `AbsCoeff`, and also the subtraction of `DstConst` from `SrcConst`. This patch resolves the issues with the strong SIV test in both llvm#159846 and llvm#164246.
…extends it is supposed to. (llvm#166710) If we visit multiple root nodes, make sure the strategy chosen for other nodes includes the nodes we've already committed to remove. This can occur if have add/sub nodes where one operand is a zext and the other is a sext. We might see that the nodes share a common extension but pick a strategy that doesn't share it.
…llvm#166212) If the instruction with tied operands is a BUNDLE instruction and we handle it by replacing an operand, then we need to update the corresponding internal operands as well. Otherwise, the resulting MIR is invalid. The test case is degenerate in the sense that the bundle only contains a single instruction, but it is sufficient to exercise this issue.
…ied (llvm#165575) If multiple action options are specified on the command line, list them all in the error message that is emitted Fixes llvm#79458
…166768) Otherwise these tests are reliant on the compiler defaulting to having the extensions on. Rest of LLVM's codebase doesn't seem to make such assumptions. Tested by building with `-std=c2y` in Clang's C frotend's config file.
…he DAG worklist (llvm#166819) As StoredVal has been replaced with a fresh load, and has one less user, make sure we add the remaining user(s) back to the worklist in case this opens further folds.
Generalize and unify testing of isa/cast/dyn_cast for various recipes, making it easier to extend with additional casts.
This enables testing with PDB for all tests that don't require any changes to pass. I ran the `lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic` tests locally and they passed.
Summary: I made that an unimplemented error, but forgot that it was used for this environment variable.
fixes llvm#165051 This change reverts the experiment we did for llvm#165311 While some backends seem to support llvm.assume without validation The validator itself does not so it makes more sense to just remove it.
) Main executables were bypassing the locate module callback that shared libraries use, preventing custom symbol file location logic from working consistently. This PR fix this by * Adding target context to ModuleSpec * Leveraging that context to use target search path and platform's locate module callback in ModuleList::GetSharedModule This ensures both main executables and shared libraries get the same callback treatment for symbol file resolution. --------- Co-authored-by: George Hu <hyubo@meta.com> Co-authored-by: George Hu <georgehuyubo@gmail.com>
A global offset table is a section that holds the address of functions that are dynamically linked. The Swift plugin needs to know if sections are a global offset table or not.
Looks like llvm#166517 is breaking libc-riscv32-qemu-yocto-fullbuild-dbg build due to failing overflow test for strfrom. https://lab.llvm.org/buildbot/#/changes/58668 ``` int result = func(buff, sizeof(buff), "%.2147483647f", 1.0f); EXPECT_LT(result, 0); ASSERT_ERRNO_FAILURE(); ``` ``` [ RUN ] LlvmLibcStrfromdTest.CharsWrittenOverflow /home/libcrv32buildbot/bbroot/libc-riscv32-qemu-yocto-fullbuild-dbg/llvm-project/libc/test/src/stdlib/StrfromTest.h:493: FAILURE Expected: result Which is: 0 To be less than: 0 Which is: 0 /home/libcrv32buildbot/bbroot/libc-riscv32-qemu-yocto-fullbuild-dbg/llvm-project/libc/test/src/stdlib/StrfromTest.h:494: FAILURE Expected: 0 Which is: 0 To be not equal to: static_cast<int>(libc_errno) Which is: 0 [ FAILED ] LlvmLibcStrfromdTest.CharsWrittenOverflow Ran 8 tests. PASS: 7 FAIL: 1 ``` At first glance it seem like there is some kind of overflow in internal::strfromfloat_convert on 32bit archs because the other overflow test case is passing for snprintf. Interestingly, it passes on all other buildbots, including libc-arm32-qemu-debian-dbg. This issue likely wasn't introduced by llvm#166517 and was probably already present, so I'm not reverting the change just disabling the test case on riscv32 until I can debug properly.
…de braced initializers (llvm#166180) Fixes llvm#163498 --- This PR addresses the issue of confusing diagnostics for lambdas with init-captures appearing inside braced initializers. Cases such as: ```cpp S s{[a(42), &] {}}; ``` were misparsed as C99 array designators, producing unrelated diagnostics, such as `use of undeclared identifier 'a'`, and `expected ']'` --- https://github.com/llvm/llvm-project/blob/bb9bd5f263226840194b28457ddf9861986db51f/clang/lib/Parse/ParseInit.cpp#L470 https://github.com/llvm/llvm-project/blob/bb9bd5f263226840194b28457ddf9861986db51f/clang/lib/Parse/ParseInit.cpp#L74 https://github.com/llvm/llvm-project/blob/bb9bd5f263226840194b28457ddf9861986db51f/clang/include/clang/Parse/Parser.h#L4652-L4655 https://github.com/llvm/llvm-project/blob/24c22b7de620669aed9da28de323309c44a58244/clang/lib/Parse/ParseExprCXX.cpp#L871-L879 The tentative parser now returns `Incomplete` for partially valid lambda introducers, preserving the `lambda` interpretation and allowing the proper diagnostic to be issued later. --- Clang now correctly recognizes such constructs as malformed lambda introducers and emits the expected diagnostic — for example, “capture-default must be first” — consistent with direct initialization cases such as: ```cpp S s([a(42), &] {}); ```
The low hanging fruit that was causing the vast majority of these warnings has been fixed, so reenable them now. There are still a couple more warnings that could probably do with some cleanup, but those can be fixed in the future.
This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. Fix BR_CC/MEMCPY descriptions to match C++ code that creates the nodes (an error detected by the enabled verification functionality). Also remove redundant `SDNPOutGlue` on `BPFISD::MEMCPY`. Part of llvm#119709.
…lvm#162822) Check that all partial reductions in a chain are only used by other partial reductions with the same scale factor. Otherwise we end up creating users of scaled reductions where the types of the other operands don't match. A similar issue was addressed in llvm#158603, but misses the chained cases. Fixes llvm#162530. PR: llvm#162822
…tions (llvm#166776) Seeing warnings: llvm/include/llvm/CodeGen/LibcallLoweringInfo.h:15:46: error: 'visibility' attribute ignored [-Werror=attributes] 15 | LLVM_ABI const RTLIB::RuntimeLibcallsInfo &RTLCI; llvm/include/llvm/CodeGen/LibcallLoweringInfo.h:18:25: error: 'visibility' attribute ignored [-Werror=attributes] 18 | RTLIB::Unsupported};
Fix shared library linking failure for FIROpenACCTransforms
…llvm#166674) Remove the unnecessary sleep in MachProcess::AttachForDebug. The preceding comment makes it seem like it's necessary for synchronization, though I don't believe that's the case (see below), and even if it were, sleeping is not a reliable way to achieve that. The reason I don't believe it's necessary is because after we return, we synchronize with the exception thread on a state change. The latter will call and update the process state, which is exactly what we synchronize on. I was able to verify that this is the first time we change the process state: i.e., `GetState` doesn't return a different value before and after the sleep. On top of that, there are 3 more places where we call ptrace attach (`PosixSpawnChildForPTraceDebugging`, `SBLaunchForDebug`, and `BoardServiceLaunchForDebug`) where we don't sleep. rdar://163952037
…lvm#153603) This enables printing, for example, the attribute value from a mismatched predicate. Example of resultant output (here made non-negative report value seen as sign-extended int): ``` PDL/ops.mlir:21:1: error: 'pdl.pattern' op attribute 'benefit' failed to satisfy constraint: 16-bit signless integer attribute whose value is non-negative (got -31) pdl.pattern @rewrite_with_args : benefit(-31) { ^ ``` This is primarily the mechanism and didn't change any existing constraints. I also attempted to keep the error format as close to the original as possible - but did notice 2 errors that were inconsistent with the rest and updated them to be consistent.
…lvm#166864) This allows for their reuse inside llvm-zorg. Otherwise we get an error that we cannot use reusable workflows inside job steps because Github thinks that they are reuseable workflows rather than composite actions. This should be NFC inside the monorepo.
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [actions/attest-build-provenance](https://redirect.github.com/actions/attest-build-provenance) | action | major | `v1.4.4` -> `v3.0.0` | | [actions/checkout](https://redirect.github.com/actions/checkout) | action | major | `v4.3.0` -> `v5.0.0` | | [actions/github-script](https://redirect.github.com/actions/github-script) | action | major | `v7.1.0` -> `v8.0.0` | | [actions/github-script](https://redirect.github.com/actions/github-script) | action | major | `v6.4.1` -> `v8.0.0` | | [actions/labeler](https://redirect.github.com/actions/labeler) | action | major | `v4.3.0` -> `v6.0.1` | | [actions/setup-node](https://redirect.github.com/actions/setup-node) | action | major | `v4.4.0` -> `v6.0.0` | | [actions/setup-python](https://redirect.github.com/actions/setup-python) | action | major | `v5.6.0` -> `v6.0.0` | | [github/codeql-action](https://redirect.github.com/github/codeql-action) | action | major | `v2.28.1` -> `v4.31.2` | | [github/codeql-action](https://redirect.github.com/github/codeql-action) | action | major | `v3.31.2` -> `v4.31.2` | | [node](https://redirect.github.com/actions/node-versions) | uses-with | major | `18` -> `24` | | [tj-actions/changed-files](https://redirect.github.com/tj-actions/changed-files) | action | major | `v46.0.5` -> `v47.0.0` |
…#166635) Recently I've been deep diving ELF cores in LLDB, aspiring to move LLDB closer to GDB in capability. One issue I encountered was a system lib losing it's unwind plan when loading the debuginfo. The reason for this was the debuginfo has the eh_frame section stripped and the main executable did not. The root cause of this was this line in [ObjectFileElf](https://github.com/llvm/llvm-project/blob/163933e9e7099f352ff8df1973f9a9c3d7def6c5/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp#L1972) ``` // For eTypeDebugInfo files, the Symbol Vendor will take care of updating the // unified section list. if (GetType() != eTypeDebugInfo) unified_section_list = *m_sections_up; ``` This would always be executed because CalculateType can never return an eTypeDebugInfo ``` ObjectFile::Type ObjectFileELF::CalculateType() { switch (m_header.e_type) { case llvm::ELF::ET_NONE: // 0 - No file type return eTypeUnknown; case llvm::ELF::ET_REL: // 1 - Relocatable file return eTypeObjectFile; case llvm::ELF::ET_EXEC: // 2 - Executable file return eTypeExecutable; case llvm::ELF::ET_DYN: // 3 - Shared object file return eTypeSharedLibrary; case ET_CORE: // 4 - Core file return eTypeCoreFile; default: break; } return eTypeUnknown; } ``` This makes sense as there isn't a explicit sh_type to denote that this file is a debuginfo. After some discussion with @clayborg and @GeorgeHuyubo we settled on joining the exciting unified section list with whatever new sections were being added. Adding each new unique section, or taking the section with the maximum file size. We picked this strategy to pick the section with the most information. In most scenarios, LHS should be SHT_NOBITS and RHS would be SHT_PROGBITS. Here is a diagram documenting the existing vs proposed new way. <img width="1666" height="1093" alt="image" src="https://github.com/user-attachments/assets/73ba9620-c737-439e-9934-ac350d88a3b5" />
…llvm#166494) `inttoptr` usage in global initialisers is valid, and rather common when it comes to the machinery around vtables (construction vtables are particularly fond). This was not handled by the BE, even though SPIR-V allows forming `SpecConstantOp`s with the `OpConvertUToPtr` opcode, which is what these would map to. We augment instruction selection to address this.
It is possible to run into situations where no mcpu is specified for an offload device side compilation. Currently, this'd lead to a rather uninformative blank being presented as the target for a failing compilation, when messaging the error count. This patch changes things so that if there is no `-mcpu` we print the triple, which is slightly more helpful, especially when there are multiple offload targets for a single compilation.
This was causing workflow failures when PRs were opened. Revert the upgrade for now so that this can be investigated and fixed before relanding.
breaks smoke no-looo-sched and openmpapps snap-mp4 MI-Teams This reverts commit 670c453.
Collaborator
dpalermo
approved these changes
Nov 7, 2025
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.