Open
Conversation
…ks (llvm#189522) Add `utils::diagDeprecatedCheckAlias` so checks can detect whether they are running under a deprecated name without enabling the new names. This commit also comes with an example with `zircon` module. It is deprecated in 22 release but we didn't provide a note for it before.
…#191797) These #includes are only needed in the SimpleRemoteEPC.cpp implementation.
…vm#191622) They have never existed since the initial public checkin.
For primitive array elements, we would accidentally activate the element and then immediate de-activate the array root, which is wrong. Ignore the element from the beginning to the later check never even compares with the element.
It's fine if they are uninitialized.
…ax. (llvm#191799) Extend test coverage with dedicated epilogue vectorization tests for dead first-order recurrences and FMinMaxNum reductions. Add users to FORs in existing tests where the dead FORs appeared unintentional.
As requested by @erichkeane here: llvm#190329 (comment)
…pe builtins (llvm#190969) When promoting scalar arguments to vectors for builtins like `ldexp`, `pown`, and `rootn`, use the correct vector type matching the argument element type instead of always using the return type: these builtins take an integer argument but at the same time have floating point return type Fix `ldexp` test that does not pass spirv-val and add similar tests for `pown` and `rootn` related to llvm#190736
Pass GISelValueTracking* through isKnownNeverNaN and isKnownNeverSNaN so that the implementation can call computeKnownFPClass to derive NaN information from value tracking, rather than only looking at flags and direct constant definitions. Update all callers. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…lvm#190519) Most clients don't have a notion of "address" and pass arbitrary values (including `0` and `sizeof(void *)`) to `DataExtractor` constructors. This makes address-extraction methods dangerous to use. Those clients that do have a notion of address can use other methods like `getUnsigned()` to extract an address, or they can derive from `DataExtractor` and add convenience methods if extracting an address is routine. `DWARFDataExtractor` is an example, where the removed methods were actually moved. This does not remove `AddressSize` argument of `DataExtractor` constructors yet, but makes it unused and overloads constructors in preparation for their deletion. I'll be removing uses of the to-be-deleted constructors in follow-up patches.
Enables LC_UUID load commands to be added with the addLoadCommand method. This will be used in future MachOPlatform changes to add support for adding UUIDs to MachO JITDylibs.
…#175870) Replace the manual check in `verifyRemoved()` with `AssertingVH` instrumentation. For cases where the leader table becomes very large, this is a cheaper way to verify we don't have dangling entries in the leader table. For this change, we must implement a move constructor for `AssertingVH` so that we can keep the first entry as an inline-allocated node that will be handled correctly as the table grows.
Part of the work to remove trivial VP intrinsics from the RISC-V backend, see https://discourse.llvm.org/t/rfc-remove-codegen-support-for-trivial-vp-intrinsics-in-the-risc-v-backend/87999 This PR expands four intrinsics before codegen, but doesn't remove the codegen handling yet as both DAGCombiner and type legalization can create these nodes. vp.fneg and vp.fpext are expanded in lockstep with the fma/fmuladd intrinsics since some test cases for vfmacc etc. also use these intrinsics, and mixing dynamic and constant vls causes some of the more complex patterns to be missed. The fixed-length VP vfmacc, vfmsac, vfnmacc and vfnmsac tests also need to replace the EVL of the vp.merge/vp.select with an immediate otherwise the resulting vmerge.vvm can't be folded into them. This only happens for fixed vector intrinsics with no passthru, since we end up with a constant vl from the fixed vector and dynamic vl from the vp.merge that prevents folding. As far as I'm aware we don't emit fixed length vp.merges in practice, since we only emit vp.merge in the loop vectorizer, and we only use it with EVL tail folding which requires a scalable VF.
This patch fixes 2 problems in lldb-server argument parser: 1. Let's try to start lldb-server with incorrect arguments ``` ./lldb-server platform --listen *:1111--server ``` Current behavior * lldb-server run in gdbserver mode with port 1111 Expected behavior * fail, as `1111–server` is not a number 2. And try to start lldb-server with host:port specification without colon ``` ./lldb-server gdbserver 1111 ./test Launched './test' as process 186... lldb-server-local_build lldb-server: llvm-project/lldb/source/Host/common/TCPSocket.cpp:245: virtual Status lldb_private::TCPSocket::Listen(llvm::StringRef, int): Assertion `error.Fail()' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: ./lldb-server gdbserver 1111 ./test Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 lldb-server 0x0000002ab86d0ca2 1 lldb-server 0x0000002ab86ced06 2 lldb-server 0x0000002ab86d1428 3 linux-vdso.so.1 0x0000003f8e7fd800 __vdso_rt_sigreturn + 0 4 libc.so.6 0x0000003f8e2b264a 5 libc.so.6 0x0000003f8e27b1ac gsignal + 18 6 libc.so.6 0x0000003f8e26c14c abort + 180 7 libc.so.6 0x0000003f8e2760cc 8 libc.so.6 0x0000003f8e27610e __assert_perror_fail + 0 9 lldb-server 0x0000002ab86eb628 10 lldb-server 0x0000002ab86f1010 11 lldb-server 0x0000002ab86eeee0 12 lldb-server 0x0000002ab86eee5c 13 lldb-server 0x0000002ab863ef3a 14 lldb-server 0x0000002ab864067c 15 lldb-server 0x0000002ab86438da 16 libc.so.6 0x0000003f8e26c476 17 libc.so.6 0x0000003f8e26c51e __libc_start_main + 116 18 lldb-server 0x0000002ab863ce64 Aborted ``` We expect to see an error instead of lldb-server crash in this case
…#191359) Both implementations are currently equivalent. This is likely a leftover from the past, when `llvm::Optional` existed.
Expose existing trylock internal operation to posix interface. POSIX.1-2024 only specifies the `EBUSY` error case. Assisted-by: Codex with gpt-5.4 default fast
Part of the work to remove trivial VP intrinsics from the RISC-V backend, see https://discourse.llvm.org/t/rfc-remove-codegen-support-for-trivial-vp-intrinsics-in-the-risc-v-backend/87999 This splits off 4 intrinsics from llvm#179622.
…191819) This change aims to make it easier for MachOPlatform clients to customize JITDylib MachO headers. At MachOPlatform construction time clients can now supply a MachOPlatform::HeaderOptionsBuilder. The supplied callback will be called by setupJITDylib to create the HeaderOptions for the JITDylib being set up. No testcase: Constructing a MachOPlatform instance requires the ORC runtime, which we can't require for LLVM unit or regression suite tests. We should look at testing this functionality in the new ORC runtime once it's ready.
For a loop-nest-generating construct this function returns the number of loops in the generated loop nest. A loop-nest-transformation construct can be thought of as replacing N nested loops with K nested loops, where N = GetAffectedNestDepthWithReason K = GetGeneratedNestDepthWithReason
This change improves the lifetime safety checker to detect when
constructor parameters escape to class fields and suggest appropriate
`[[clang::lifetimebound]]` annotations.
```cpp
struct A {
View v;
A(const MyObj& obj) : v(obj) {} // Now suggests [[clang::lifetimebound]]
};
```
…lvm#191834) …cess). 6dbf9d1 forward declared the MemoryAccess class in ExecutorProcessControl.h, breaking some examples that were depending on the transitive include. (See e.g. https://lab.llvm.org/buildbot/#/builders/80/builds/21875). This commit adds the missing #includes to the broken examples.
These are now listed in the asciidoc spec here https://github.com/riscv/riscv-p-spec I got some help on this from AI, but I reviewed it. Test cases were fully generated with AI.
…m#191818) Add GICv5 `ICH_PPI_HVIR{0,1}_EL2` system registers (Interrupt Controller PPI Hide Virtual Interrupt Registers). These registers are added because a hypervisor may want to only expose a subset of the PPIs to the virtual machine and hide the remaining PPIs. The only way the hypervisor can do this is by trapping all the PPI ICV registers which leads to additional code complexity and adds performance overhead especially for nested virtualization. These are documented here: https://developer.arm.com/documentation/111107/latest/AArch64-Registers/ICH-PPI-HVIR-n--EL2--Interrupt-Controller-PPI-Hide-Virtual-Interrupt-Registers
…follow LLVM conventions (llvm#191134) Follow-up to #[189948](llvm#189948 (comment)). Addresses review feedback Co-authored-by: padivedi <padivedi@amd.com>
…kernels (llvm#191770) Don't use the L0 heuristics if all the dimensions are specified by the user code.
…#190026) Add translation from the MLIR OpenMP depend clause with iterator modifier to LLVM IR. `buildDependData` (in OpenMPToLLVMIRTranslation) allocates a single `kmp_depend_info` array sized to hold both locator (non-iterated) and iterated entries. Locator dependencies use the existing static path (a vector of `DependData`), while iterated dependencies use a dynamically-sized path (`DepArray`, `NumDeps`). The reason both paths are not unified under the dynamic allocation is that the existing locator path emits actual `kmp_depend_info` entries inside OMPIRBuilder methods (`createTask`, `createTarget`), whereas the iterator path must emit the iterator loop in OpenMPToLLVMIRTranslation (since the convention is to not pass MLIR ops into the OMPIRBuilder). Unifying them would require modifying existing depend clause tests. The `OMPIRBuilder::DependenciesInfo` struct is extended to hold either a `SmallVector<DependData>` (locator path) or a pre-built `{DepArray, NumDeps}` pair (iterator path). The single-entry `emitTaskDependency` helper is made public so the translation layer can fill individual `kmp_depend_info` entries inside the iterator loop body. This patch is part of the feature work for llvm#188061. Assisted with copilot.
This is a set of squashed reverts of recent clang doc patches, since its breaking something on Darwin builders: https://lab.llvm.org/buildbot/#/builders/23/builds/19172 Revert "[clang-doc][nfc] Default initialize all StringRef members (llvm#191641)" This reverts commit 155b9b3. Revert "[clang-doc] Initialize StringRef members in Info types (llvm#191637)" This reverts commit 489dab3. Revert "[clang-doc] Initialize member variable (llvm#191570)" This reverts commit 5d64a44. Revert "[clang-doc] Merge data into persistent memory (llvm#190056)" This reverts commit 21e0034. Revert "[clang-doc] Support deep copy between arenas for merging (llvm#190055)" This reverts commit c70dae8.
This PR improves native binary generation by avoiding `llvm::sys::ExecuteAndWait` call for ocloc and instead leveraging `oclocInvoke()` that consumes an in-memory SPIR-V string. Co-authored-by: Artem Kroviakov <artem.kroviakov@intel.com>
Revert "[TySan][Sanitizer Common] Make TySan compatible with sanitizer common… (llvm#183310)" and "[TySan][Sanitizer Common] Enable TySan testing in the sanitizer commo… (llvm#191385)" This reverts commit d043b9e and dd0c5eb. d043b9e broke the macOS bots https://ci.swift.org/job/llvm.org/job/clang-stage1-RA-cmake-incremental/job/main/638/consoleFull#-1919712802f80d942a-f672-4696-b0d9-c66cae8aa9dd with an error that looks like: ``` /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/compiler-rt/lib/tysan/../sanitizer_common/sanitizer_signal_interceptors.inc:136:3: error: expected expression 136 | INIT_SIGNAL; | ^ /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/compiler-rt/lib/tysan/../sanitizer_common/sanitizer_signal_interceptors.inc:77:21: note: expanded from macro 'INIT_SIGNAL' 77 | #define INIT_SIGNAL COMMON_INTERCEPT_FUNCTION(signal) | ^ /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/compiler-rt/lib/tysan/tysan_interceptors.cpp:51:41: note: expanded from macro 'COMMON_INTERCEPT_FUNCTION' 51 | #define COMMON_INTERCEPT_FUNCTION(name) TYSAN_INTERCEPT_FUNC(name) | ^ /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/compiler-rt/lib/tysan/tysan_interceptors.cpp:27:34: note: expanded from macro 'TYSAN_INTERCEPT_FUNC' 27 | if (!INTERCEPT_FUNCTION(name)) ``` unfortunately reverting just d043b9e doesn't work cleanly because another commit (dd0c5eb) enabled testing and the testing fails when we revert just d043b9e. So this commit reverts dd0c5eb too. It would've been nice to have to separate revert commits but it seems GitHub won't let me do this and forces commits to be squashed. rdar://174648152
…er commo…" (llvm#191902) Reverts llvm#191385 Some tests seem to be failing, but not under all environments, possibly due to non-tysan related reasons. Clearly I need to look more into this before enabling this
…1900) Reverts llvm#191657 Broke Fuchsia CI.
with processBuildVector, NFC processBuildVector adjusts the scalars to match the entry vector factor, while calculateTreeCostAndTrimNonProfitable does not. Sync the behovior to avoid potential issues. Currently it does not affect the cost estimations, so it is NFC. Reviewers: Pull Request: llvm#191905
…#190938) Orginal PR: llvm#184931 Original PR message: This patch enables FindLast reduction vectorization with scalable vectors on RISCV. Fixed the previous crash by llvm#191166 and llvm#191517
…#191132) When loading a crashlog using scripted process, inlined frames get lost. This happens because `ScriptedThread::LoadArtificialStackFrames` creates all frames as concrete frames via `SetFrameAtIndex`, completely bypassing the inline frame synthesis that `StackFrameList::FetchFramesUpTo` normally performs using `GetParentOfInlinedScope`. Since two crashlog frames share the same PC when one is inlined into the other, `CalculateSymbolContext` resolves both to the innermost inlined scope, which causes the containing function to be dropped from the backtrace. This patch fixes the issue in two parts: - On the Python side, `resolve_stackframes` now skips frames whose PC matches the next frame's PC. These are inlined frames that LLDB will synthesize from debug info when it processes the concrete frames we provide. Indices are renumbered accordingly, and `len(frames) == 0` is used for first-frame detection. - On the C++ side, `LoadArtificialStackFrames` now replicates the inline synthesis loop from `FetchFramesUpTo`: after creating each concrete frame, it calls `GetParentOfInlinedScope` in a loop and creates a `StackFrame` for each inlined parent scope. rdar://154981041 Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
…vm#191316) Lambda captures of variables that require destruction requires us to created cleanup scopes with deferred deactivation. That is, the cleanup scope is created, but added to a list that automatically deactivates the cleanup when we exit the scope in the compiler code where the lambda is being generated. This deferred deactivation mechanism will be needed for other use cases as well, so it is implemented in a general way, which closely follows the classic codegen handling. Assisted-by: Cursor / claude-4.6-opus-high
…m#191836) GH191833 reports a problem with tree transformation of a collapse clause when the expression in the clause is invalid. This patch makes sure we skip out of transforming this clause if it ever encounters an invalid expression. I also analyzed the rest of the clauses in this visitor and found 1 other that was suspicious, so I added a check for that one as well. The rest seemingly were all done correctly. Fixes: llvm#191833
…arrier (llvm#191858) AMDGPULowerIntrinsics downgrades s_barrier/s_barrier_wait to wave_barrier on single-wave workgroups, but dropped all metadata from the original instruction. The lost !noalias and !alias.scope metadata prevented MemorySSA's optimized walker from skipping past the barrier, causing isClobberedInFunction to walk further and reach unrelated side-effecting defs (e.g. tensor_load_to_lds) that are misclassified as clobbers — ultimately losing !amdgpu.noclobber on global loads. Copy !noalias, !alias.scope, and !tbaa from the old instruction to the replacement wave_barrier. Made-with: Cursor
When binaries have been loaded into a process on Darwin, lldb sends a jGetLoadedDynamicLibrariesInfos packet to get the filepath, uuid, load address, and detailed information from the mach header/load commands. For a large UI app, the number of binaries that can be loaded (through various dependencies) can exceed a thousand these days, and requesting detailed information on all of those can result in debugserver allocating too much memory when running in constrained environments, and being killed. In 2023 I laid the groundwork to fetch detailed information in chunks, instead of one large request. The main challenge with this is when we first attach to a process that is running, we send a "tell me about all binaries loaded", and that prevents lldb from chunking the reply; the packet design for jGetLoadedDynamicLibrariesInfos assumes the entire reply is sent in one packet, instead of the typical gdb remote serial protocol trick of a response with partial data starting with 'm' and a response with a complete reply starting with 'l'. The 2023 change is to add a new key to this packet, `report_load_commands` and when that is set to `false`, only the load address of the binaries is reported. lldb then uses the array of load addresses of all the binaries to fetch detailed information about them in smaller groupings. This PR implements the lldb side of that work. Process::GetLoadedDynamicLibrariesInfos now takes a `bool include_mh_and_load_commands`, ProcessGDBRemote sends that as an argument in the jGetLoadedDynamicLibrariesInfos packet. DynamicLoaderMacOS::DoInitialImageFetch is changed to only get the load addresses on initial attach. If the reply includes the full binary information (not just load addresses) -- when talking to an old debugserver -- we will use that information instead of re-fetching it. On a newer debugserver that only sent the load addresses, we'll send this list of addresses to the standard method we use when dyld has told us to load binaries at addresses already. DynamicLoaderMacOS::AddBinaries, which takes a list of addresses and fetches detailed information about them, is updated to request only 600 binaries at a time. A typical UI app will be in the 700-1000 binary range these days, so this will turn one large fetch into two, in most cases. There are some system UI processes that have many dependencies that could require three fetches. I picked this number so most debug sessions will be handled by two requests. In debugserver MachProcess::FormatDynamicLibrariesIntoJSON, I removed the obsolete-for-three-years-now `mod_date` field. I was sending back the binary filepaths for this "don't send the detailed information" version of the packet - I don't need that, and it just increases the size, so I stopped sending filepaths in this mode. I also added a new field for when we ARE sending detailed information, `sizeof_mh_and_loadcmds`. I don't use this in lldb yet, but when we are told about a binary and need to read it from memory today, we have an initial read to get the mach header, which tells us the size of the load commands. Then we have a second read of the mach header plus load commands, before we can start binary processing in earnest. This is an extra read packet and very unnecessary, given that debugserver knows how large the mach header + load commands are. So I'm returning it here, and at some point I'll find a way to pipe that into a new memory object file creation method in lldb. It's one of those "I should really find a way to remove that extra read some day" cleanups, and while I was in this area, I'd add this first piece of that. I don't have a test for this. I've been thinking about an API test that creates 700 dylibs with empty functions in each, runs it, and confirms all of the dylibs were loaded. I'd have to grab a packet log to be completely sure we didn't read the full binary list in one go. But I worry that compiling and linking even 700 do-nothing dylibs might be too much. Maybe I should add a setting in DynamicLoaderMacOS::AddBinaries to reduce the maximum number of binaries that can be read at once, and have a small nubmer of dylibs. When by-hand testing this, I had a maximum of 5 binaries being queried in one packet. rdar://109428337
llvm#191893) We are seeing test failures in "passthrough-lld.test" as LIT substitutes the "ld.lld" string in the test file to the full path to the lld. However, the "-flavor" flag does not expect a full path. It just need a name of the linker so it fails. This patch modifies the lld matching regex in the use_lld function in llvm/utils/lit/lit/llvm/config.py. It prevents LIT from substitute any lld tool strings that are not standalone.
This can be used to make sure the stack tagging does not use the top bit of the pointer. This is useful when HWASan is used in combination with signed-integer-overflow detection. Some code uses arithmetic on intptr_t that overflows for sufficiently large pointers.
…189657)" (llvm#191912) This reverts commit 67c893e due to buildbot breakage (llvm#189657 (comment), llvm#189657 (comment)).
Extend copyMetadata to every call-to-call replacement in AMDGPULowerIntrinsics, not just the single-wave s_barrier → wave_barrier path. This covers: - s_cluster_barrier → wave_barrier (single-wave) - s_cluster_barrier → signal_isfirst + wait + signal + wait (multi-wave) - s_barrier → signal + wait (split barriers) Add GFX11 and GFX12 RUN lines and test functions for all lowering paths to verify metadata preservation. Made-with: Cursor
…1925) Closes llvm#191910 --------- Co-authored-by: Joseph Huber <huberjn@outlook.com>
…lvm#191745) This reverts commit 4abb927. The code is not needed since 121f5a9 because the C compiler is now always just-built clang in in-tree build. In addition, CMAKE_AR is llvm-ar and CMAKE_RANLIB is llvm-ranlib.
…fier (llvm#191849) Currrently the signature of `result(..)` is: ```python result(*, infer_type: bool = False, default_factory: Callable[[], Any] | None = None, kw_only: bool = False) -> Result ``` so when users use `result(infer_type=True)`, the type checkers will still get `kw_only=False` (from the signature), but actually the `kw_only` should be `True` (it should follow the value of `infer_type`). users can use `result(infer_type=True, kw_only=True)` but it's unnecessarily verbose. So it may introduce an incompatibility when we start to use `dataclass_transform`. currently it's fine because we just don't use `dataclass_transform`. But when we use, we may require a breaking change. This PR migrates such use to a new field specifier named `infer_result()`.
These seemed to have gotten removed here.
z1-cciauto
requested review from
Groverkss,
antiagainst,
kuhar,
nicolasvasilache and
stellaraccident
as code owners
Collaborator
Author
|
PSDB Build Link: http://mlse-bdc-20dd129:8065/#/builders/11/builds/212 |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.