[SyncBots] Integrate LLVM#8
Closed
WuXintong123 wants to merge 3380 commits into
Closed
Conversation
EmitCMP folds `c CMP rhs` into `rhs CMP' c+1` for four condition codes. The `c+1` must wrap modulo the i16 operand width, but the current code does `DAG.getConstant(C->getSExtValue() + 1, dl, MVT::i16)`: sign-extending to `int64_t`, adding there, then handing the result to the unsigned `getConstant(uint64_t, ..., MVT::i16)` overload. For constants with bit 15 set the negative `int64_t` is reinterpreted as a huge `uint64_t`, which trips the `isUIntN(16, val)` assertion in the APInt constructor under `LLVM_ENABLE_ASSERTIONS` and yields an APInt with non-zero bits past its declared width otherwise. Switching to `DAG.getSignedConstant(C->getSExtValue() + 1, ...)` routes through the signed `APInt` constructor, which checks `isIntN(16, val)` and accepts the negative `c+1` produced when the high bit is set. The four EmitCMP fold branches (SETUGE, SETULT, SETGE, SETLT) are updated identically.
) Summary: libclc needs to normalize triples, mostly on account of the fact that things like spv and clspv aren't real triples but are used anyway. That is, we convert the user-value to whatever is passed to `--target=`. The problem is that we were not using the normal triple for the installation directory, so something like `spirv64-mesa32-unknown` would be installed in `spirv64--`. This *might* have the side effect of putting these in `spirv64-unknown-unknown`. I actually do not know if that's a problem with the clang handling, I'll double check.
…m#196345) \llvm#192120 marked this as RequiredPassInfoMixin, deviating from previous behavior. This is probably fine for Function/Module analyses, but doesn't work well for loop analyses in the case that we have a loop in an optnone function that is not in LCSSA. The LCSSA pass will not run because it is optional, the analysis will get computed, and then we assert because the loop is out of LCSSA at the end of the LPM. Restore the old behavior of just not marking the pass as required as it seems reasonable enough.
Resolves llvm#128152. The old algorithm runs a backward DFS from `I` and marks `E` as ephemeral iff every user of `E` has already been visited. This fails when `E` has a user that the backward walk never reaches. Switch to a forward DFS from `E` so that ephemeral values are identified when the condition has other uses off the assume chain.
Fixes a few tests with the MSVC toolchain due to incompatibilities: 1. `asan_and_llvm_coverage_test.cpp`: Adds MSVC-specific linker flags (/link /NODEFAULTLIB:libcmt ...) alongside the existing clang-cl -Wl flags. It is probably better to convert these later to substitution changes in `lit.cfg.py`, but that will require upstreaming more test changes. 1. `debug_invalid_pointer_pair.cpp`: Marks the test `UNSUPPORTED: MSVC` because `-mllvm` and codegen isn't supported with MSVC. 1. `debug_memcpy_overlap.cpp` : Adds `/Oi` (enable intrinsics) when building with MSVC, so `memcpy` is emitted as a call that ASan can intercept.
…lvm#196218) Add a dedicated unit test for every standard DWARF 5 expression operator (plus the GNU extensions in use), so each opcode in the evaluator's switch has explicit coverage. Tests for opcodes that require execution context not available in a standalone evaluation (process, frame, compile unit, object address) assert that evaluation fails cleanly rather than crashing. This PR fixes one bug surfaced by the audit: DW_OP_deref_size only rejected sizes greater than 8, not sizes greater than the target's address size. The DWARF 5 spec requires the operand to be no larger than the generic type. The new check returns a clean diagnostic instead of silently dereferencing beyond the address-sized window on 32-bit targets. Assisted-by: Claude
Frontend inserted conversions may conflict with variable names. Avoid this for integer conversions by using `__builtin_int` instead of `int`. Fixes llvm#188879
Uses `CIRGenItaniumCXXABI` when generating IR for the ABI target. Co-authored-by: Justin A. Wilson <waj334@gmsil.com>
This patch adds: - a new kernel `void single_counter(int32_t init_loop, int32_t addend, uint32_t *init_val, uint32_t *out)` - a new test suite `olLaunchKernelSingleCounterSyncEventTest`, with two tests The test `SuccessSyncEvent` verifies whether `olSyncEvent(Event)` awaits the completion of `Event`. The test `SuccessTwoQueues` checks the correctness of the synchronization between queues using events. Enqueueing the kernel on the queue `Q1` should produce `Result1`, which is used as an initial value for the queue `Q2`. Therefore, before executing any future work, `Q2` should wait for the event `Event1`, which is created after submitting work on `Q1`. The required synchronization is ensured by `olWaitEvents(Q2, &Event1, 1)`. If `Q2` uses the value passed as `Result1` before the work on `Q1` has completed, the result of the kernel enqueued on `Q2` would be incorrect.
) Replace errorNYI stubs with actual cir::LLVMIntrinsicCallOp calls for: - __nvvm_fabs_f, __nvvm_fabs_d, __nvvm_fabs_ftz_f (+ f16/bf16 variants) - __nvvm_ex2_approx_f, __nvvm_ex2_approx_d, __nvvm_ex2_approx_ftz_f __nvvm_fabs_d maps to standard llvm.fabs (matching classic CodeGen), while the rest map to their respective nvvm.* intrinsics. Part of llvm#179278
…lvm#196362) `AddressSize` parameter is not used by `DataExtractor` and will be removed in the future. See llvm#190519 for more context.
Call `EnsureConnected` in the `PlatformWebInspectorWasm` ctor so the platform reports being connected after selecting in. The lazy approach resulted in confusion due to the "Connected: no" in the `platform select` output: ``` (lldb) platform select webinspector-wasm Platform: webinspector-wasm Connected: no ```
…m#190649) This makes infinities and NaNs return the new, more explicit formats added in 8d9299c and extends the base decimal output literal to support non-double types. In addition, the legacy hexadecimal floating-point literal format is no longer output in any circumstance. In general, this means that NaNs are reported as +/-qnan, +/-nan(payload), or +/-snan(payload), depending on their payload and infinities as +/-inf. The hexadecimal output generally changes to `f0x...` notation, and is used when 6 decimal digits are insufficient to accurately represent the number, or for noncanonical ppc_fp128 values. A script to change the output for most test files is available at https://gist.github.com/jcranmer-intel/d279296ad91884c98b77fb23a9112a5a. Full disclosure: the python portion of the script was written with the use of AI tools. The C++ portion was written entirely by hand, reusing LLVM's existing helpers for output. The test changes included in this commit are *only* those which do not work with that script, either because the script mangled the conversion (e.g., intentionally matching only a prefix to allow some imprecision) or because the tests were too unusual for the script to find the floating-point literals being compared against.
This preserves the existing behavior and makes the pass compliant with \llvm#192120, which is important as inheriting from the normal PassInfoMixin will be going away soonish.
Creating a feature branch. New Console Pane that - - captures stdout/stderr msgs from debugged process - displays output to console in real-time - provides scrolling and navigation features - manages 10K line circular buffer - auto-scroll on/off feature <img width="2940" height="1744" alt="image" src="https://github.com/user-attachments/assets/49e9dd3e-9f6f-4383-820b-ce365a46208f" /> Controls - enable / disable : F5 + o tab to switch to Console pane UP/ DOWN / PAGEUP/ PAGEDOWN for scrolling, HOME/ END for top or bottom c for clear output Tested on Mac
As part of the NonNarrowingCastsOptimization we were optimizing away some cases where the inner input was an integer and the outer output was a float. Not all of the resulting dtype combinations for these cases are supported by TOSA, so these scenarios are no longer optimized as part of canonicalizations. --------- Signed-off-by: Ian Tayler Lessa <ian.taylerlessa@arm.com>
…r `-gpu=mem:unified` (llvm#196228) Under `-gpu=mem:unified`, plain Fortran module-scope variables referenced directly from a `global` kernel previously produced wrong results. This adds a `cuda-unified` option to the CUF passes: - CUFDeviceGlobal: when set, plain (un-attributed, non-constant) module globals are mirrored into the GPU module as no-body declarations, so PTX emits `.extern .global ...`. - CUFAddConstructor: when set, emits a CUFRegisterExternalVariable call for each such global from `__cudaFortranConstructor`. - New runtime entry `CUFRegisterExternalVariable` wraps `__cudaRegisterHostVar` so the CUDA driver maps the device extern to the host pointer at module-load time. HMM/ATS handles migration from there.
-frepack-arrays (implied by -Ofast) was inserting fir.pack_array / fir.unpack_array for assumed-shape dummy arguments with CUDA data attributes (device, managed, etc.). The repacking allocates a host-side temporary and copies the descriptor, but the data lives in device memory. When the CUF kernel subsequently receives the host descriptor pointer, accessing it from the GPU triggers cudaErrorIllegalAddress. Skip repacking in needsRepack() for any symbol that carries a CUDA data attribute.
…etCallee (llvm#196204) IndirectCallEdge::GetCallee calculates the raw address of a function pointer and tries to resolve a load address for it. If the function pointer has metadata bits in it (e.g. a signed pointer in arm64e) then the resolution will fail. --------- Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
…symbolication.cpp (llvm#196380) Somehow, llvm#196152 fixed a bug where the x86_64h feature wasn't getting correctly set and so some tests that weren't running before started running. One such test is [AddressSanitizer-x86_64-darwin.TestCases/Darwin.haswell-symbolication.cpp](https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-RA-cmake-incremental/job/main/872/testReport/AddressSanitizer-x86_64-darwin/TestCases_Darwin/haswell_symbolication_cpp/), which appears to have never been updated for the internal lit shell. The internal lit shell does not support sub-shells, so the typical pattern appears to be to write results to a file and use `%{readfile:%t.whatever}`. rdar://176390171
) On Windows, offload-arch fails to find or loads the wrong amdhip64 DLL when running from a source-built LLVM/Clang installation where the executable and HIP runtime are in different subdirectories. Three fixes: 1. getSearchPaths(): walk parent directories appending /bin to each, so layouts like <root>/lib/llvm/bin/offload-arch can discover <root>/bin/amdhip64_*.dll. Capped at 6 levels with root detection. Case-insensitive dedup for Windows paths. 2. findNewestHIPDLL(): use stable_sort to preserve search-path order on version ties, so a colocated build DLL wins over a system copy. 3. printGPUsByHIP(): prime the DLL load with LoadLibraryExW and LOAD_WITH_ALTERED_SEARCH_PATH so transitive dependencies resolve from the DLL own directory. Uses LLVM convertUTF8ToUTF16String for path conversion. Also fixes two pre-existing bugs: inverted current_path error check (line 138) and missing break in HipApiVersion switch (line 421). --------- Co-authored-by: Samiii777 <Samiii777@users.noreply.github.com>
This PR was started because I noticed bugs in the docs: - The interestingness test checked for an error, but did not redirect stderr to stdout to include it in the pipe. - The interestingness test pipe ended with grep, but then checked for an exit code of 1 to mark the input as interesting. However, a pipe's overall exit code is the exit code of the rightmost command, and grep's exit code is zero when it detects the query string, and 1 when it does not detect the query string. So the test was backwards. Then I wanted to test my fixes to be sure I got it right, and I realized that the doc has no properly runnable example. This PR adds a working example. h/t @aidint for fixing up the input.
…lvm#195348) When multiple prefetch hints target the same external symbol, only the first one should provide the weak fallback definition. This avoids multiple definitions of the same symbol in the generated assembly.
…structions (llvm#195266) The intra-block path previously gated on isCSINCInstruction, restricting optimization to CSINC. Replace the gate with findCondCodeUseOperandIdxForBranchOrSelect(), which covers the full select family: CSEL, CSINC, CSINV, CSNEG, and FCSEL.
…ment indices only generate poison (llvm#196720) Matches ValueTracking / GISel implementations - although testing options are limited until DAG has actual uses of UndefPoisonKind::UndefOnly
…195542) The `toctree` section is hidden but used for previous/next breadcrumbs. This was suggested in llvm#184440 (comment)
Handle new insertReplaceSupport capability (defined in LSP 3.16). Add the new option to the protocol layer and pass it around to the code completion logic. Update CompletionItem::textEdit to become the union type as per the LSP specification. Add a new helper function to the Lexer public API to find the end of an identifier with full context lexing, to avoid duplicating the logic. Use the helper both in the Sema flow and in the comment completion flow. Use a simpler ASCII-only scan in no-Sema mode. Add LIT tests to verify auto-triggered completions, mid-word replacement, Unicode, and snippets. Add unit tests to verify insert/replace ranges with and without Sema, including comments and the feature-off case. Update the release notes to document the new capability. Fixes clangd/clangd#2190 --------- Co-authored-by: timon-ul <timon.ulrich@advantest.com>
…vm#196773) After llvm#191690, LoadJob::Archive runs in parallel and getArchiveMembers() calls ctx.tar->append() from the parallel body. TarWriter::append is unsynchronized. Member order in the tar is also non-deterministic because parallelFor scheduling determines append order. Buffer per-job tar entries during the parallel pass and flush them in the existing serial post-pass, mirroring the thinBufs / files pattern.
In order to simplify matrix casting and follow the existing pattern HLSL is doing, the matrix needs to be trivially copyable. related to: llvm#184471 --------- Co-authored-by: Joao Saffran <jderezende@microsoft.com>
Move xxHash64, xxh3_64bits, and xxh3_128bits ArrayRef/StringRef overloads from llvm/Support/xxhash.h to inline overloads in llvm/ADT/ArrayRef.h and llvm/ADT/StringRef.h, so xxhash.h has no ADT dependencies. This is prerequisite for using xxh3 as the combine_bytes backend in llvm/ADT/Hashing.h (llvm#194567), which would otherwise reintroduce a header dependency cycle. FoldingSet.h and StableHashing.h adjust to call the new pointer-and-length entry point.
Replace the CityHash-style mixer in hash_combine and (transitively) hash_value(std::basic_string), hash_value(StringRef), and therefore DenseMap<StringRef, X> lookups, with a flatten-and-call into xxh3_64bits, a modern hash superior to CityHash. hash_value(int) / hash_value(ptr) keep the existing Murmur-style hash_16_bytes mixer; those are the dominant DenseMap key paths and a fully-inline 16-byte mix beats inlining xxh3's larger 0..16-byte short path. To break dependency cycle: xxHash64, xxh3_64bits, and xxh3_128bits ArrayRef/StringRef overloads move from llvm/Support/xxhash.h to inline overloads in llvm/ADT/ArrayRef.h and llvm/ADT/StringRef.h, so xxhash.h has no ADT dependencies. A variant that inlined xxh3's 0..16-byte fast path at every combine_bytes call site (vs. always calling out-of-line xxh3_64bits) showed no measurable compile-time improvement on the tracker, so combine_bytes is a one-liner over the out-of-line entry point. llvm-compile-time-tracker.com (CTMark, instructions:u) ``` stage1-O0-g -1.76% (sqlite3 -3.78%) stage1-aarch64-O0-g -1.40% (sqlite3 -2.86%) stage1-ReleaseLTO-g -1.13% stage1-ReleaseThinLTO -0.45% stage1-O3 -0.43% stage1-aarch64-O3 -0.42% stage2-O0-g -0.42% stage2-O3 -0.15% clang build -0.71% (wall -0.42%) ``` DenseMap-of-pointer paths (dominant at -O3) are untouched, so higher- optimization configs see smaller wins as expected. opt's .text shrinks ~92 KB. Subsumes the StringRef-only carve-out proposed in llvm#191115. Notes on properties not introduced by this patch: - Endianness: hash_combine over native integers was already not cross-host stable. memcpy of a native integer into the buffer is host-encoded; fetch32 normalized the read but not the underlying bytes, so on LE vs BE the value fed to the mixer already differed. xxh3 inherits the same property: same byte stream, different mixer. - Process seed: combine_bytes XORs get_execution_seed into the result, which cancels under hash_combine(x) ^ hash_combine(y). The pre-patch short/state paths fed the seed through hash_16_bytes / shift_mix non-linearly, so this is a regression in seed effectiveness under that pattern. Default seed is constant, so this only matters under LLVM_ENABLE_ABI_BREAKING_CHECKS. Follow-up: add a seeded xxh3 entry point in libSupport. Aided by Claude opus 4.7
This has been deprecated for a while and was slated for removal after the branching of LLVM 22. Remove it since I'm on on the Google integrate rotation this week and can take care of any failures on our end.
Add a basic dl_iterate_phdr implementation so that we can get libunwind building. This implementation is bare and not fully compliant with the man page for fully static binaries (which are all that we support currently with the lack of a dynamic linker) due to the lack of TLS info, but that can be added at a future date if it is needed, as it is not needed by libunwind. Add some very basic smoke tests.
xxHash64 is a legacy, pre-XXH3 hash whose only non-test caller in the monorepo is llvm::getKCFITypeID. llvm#196774 accidentally exposed the API.
…opsrun test (#4) Fix three issues found on RISC-V: 1. Fix use-after-free in block walk (Visitors.h) When walking blocks with ReverseDominanceIterator, the Traversal object returned by Iterator::makeIterable(region) was passed as a temporary directly to llvm::make_early_inc_range(). The temporary was destroyed at the end of the full expression while iterators from make_early_inc_range still referenced it. Store the result in a local variable with auto&& to extend the lifetime of the temporary and bind lvalue references for ForwardIterator. 2. Fix Shape dialect CstrBroadcastableOp fold and cast canonicalization Extend getShapeVec to look through tensor.cast operations so that folds can resolve shapes behind casts inserted by earlier canonicalization passes (e.g., ShapeOfOpToConstShapeOp). Add a new fold check in CstrBroadcastableOp::fold that recognizes broadcasting is trivially valid when at most one operand is non-scalar (resolved via getShapeVec). Rewrite CanonicalizeCastExtentTensorOperandsPattern to use modifyOpInPlace instead of replaceOpWithNewOp to avoid issues with op builder template instantiation. 3. Fix opsrun.py test invocation pattern for multithreaded_tests.py Convert direct test_foo() calls to run(test_foo) so that copy_and_update in multithreaded_tests.py properly strips them during import, preventing JIT execution at module load time which crashes on RISC-V due to R_RISCV_HI20 relocation range limits.
WuXintong123
pushed a commit
that referenced
this pull request
May 21, 2026
) ``` Before: ext v1.16b, v0.16b, v0.16b, #8 zip1 v0.16b, v0.16b, v1.16b addv h0, v0.8h fmov w0, s0 After: addp v0.16b, v0.16b, v0.16b addp v0.16b, v0.16b, v0.16b addp v0.16b, v0.16b, v0.16b umov w0, v0.h[0] ``` The existing lowering in vectorToScalarBitmask for v16i8 used an EXT+ZIP1+ADDV sequence to pack the per-lane bits into an i16. The horizontal ADDV is expensive on some microarchitectures and forces an early SIMD-to-GPR domain crossing. Replace it with a three-level pairwise-add (ADDP) tree. After the AND with the powers-of-two constant, each byte lane holds at most one set bit within its 8-byte group, so pairwise addition cannot carry and is equivalent to OR at every level. Three ADDPs therefore losslessly pack the 16 per-lane bits into the low i16 of the result vector, from which we extract the bitmask with a single UMOV. This keeps all computation in the vector register file until the final extract and avoids the horizontal reduction. Partially addresses llvm#192749. Follow-up work can extend this transform to N=32 and N=64 by fusing across Q-registers in the first ADDP level.
WuXintong123
pushed a commit
that referenced
this pull request
Jun 7, 2026
I recently noticed LLDB crash during execution of `script print(lldb.SBDebugger().GetBroadcaster().GetName())` command: ``` PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/sergei/llvm-project/build/bin/lldb-dap #0 0x000062735c3403d2 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/sergei/llvm-project/build/bin/lldb-dap+0x7c3d2) #1 0x000062735c33d7ec llvm::sys::RunSignalHandlers() (/home/sergei/llvm-project/build/bin/lldb-dap+0x797ec) #2 0x000062735c33d94c SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0 #3 0x00007eaa6aa45330 (/lib/x86_64-linux-gnu/libc.so.6+0x45330) #4 0x00007eaa6bb0c092 lldb::SBBroadcaster::GetName() const (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x90c092) #5 0x00007eaa6bcb9a5d _wrap_SBBroadcaster_GetName LLDBWrapPython.cpp:0:0 #6 0x00007eaa6a1df5f5 (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x1df5f5) #7 0x00007eaa6a182b2c PyObject_Vectorcall (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x182b2c) #8 0x00007eaa6a11d5ee _PyEval_EvalFrameDefault (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x11d5ee) #9 0x00007eaa6a2a091f PyEval_EvalCode (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x2a091f) #10 0x00007eaa6a29c8b0 (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x29c8b0) #11 0x00007eaa6a11fbd3 _PyEval_EvalFrameDefault (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x11fbd3) #12 0x00007eaa6c4891b7 lldb_private::ScriptInterpreterPythonImpl::ExecuteOneLine(llvm::StringRef, lldb_private::CommandReturnObject*, lldb_private::ExecuteScriptOptions const&) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x12891b7) #13 0x00007eaa70326ff5 CommandObjectScriptingRun::DoExecute(llvm::StringRef, lldb_private::CommandReturnObject&) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x5126ff5) #14 0x00007eaa6bee3739 lldb_private::CommandObjectRaw::Execute(char const*, lldb_private::CommandReturnObject&) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0xce3739) #15 0x00007eaa6bede09a lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, bool) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0xcde09a) #16 0x00007eaa6bb0f0f8 lldb::SBCommandInterpreter::HandleCommand(char const*, lldb::SBExecutionContext&, lldb::SBCommandReturnObject&, bool) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x90f0f8) #17 0x00007eaa6bb0f265 lldb::SBCommandInterpreter::HandleCommand(char const*, lldb::SBCommandReturnObject&, bool) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x90f265) #18 0x000062735c3707f3 lldb_dap::RunLLDBCommands[abi:cxx11](lldb::SBDebugger&, lldb::SBMutex, llvm::StringRef, llvm::ArrayRef<lldb_dap::protocol::String> const&, bool&, bool, bool) (/home/sergei/llvm-project/build/bin/lldb-dap+0xac7f3) #19 0x000062735c3a8019 lldb_dap::EvaluateRequestHandler::Run(lldb_dap::protocol::EvaluateArguments const&) const (/home/sergei/llvm-project/build/bin/lldb-dap+0xe4019) #20 0x000062735c3aba78 lldb_dap::RequestHandler<lldb_dap::protocol::EvaluateArguments, llvm::Expected<lldb_dap::protocol::EvaluateResponseBody>>::operator()(lldb_dap::protocol::Request const&) const (/home/sergei/llvm-project/build/bin/lldb-dap+0xe7a78) #21 0x000062735c3ce1bf lldb_dap::BaseRequestHandler::Run(lldb_dap::protocol::Request const&) (/home/sergei/llvm-project/build/bin/lldb-dap+0x10a1bf) #22 0x000062735c3577e7 lldb_dap::DAP::HandleObject(std::variant<lldb_dap::protocol::Request, lldb_dap::protocol::Response, lldb_dap::protocol::Event> const&) (/home/sergei/llvm-project/build/bin/lldb-dap+0x937e7) llvm#23 0x000062735c358705 lldb_dap::DAP::Loop() (/home/sergei/llvm-project/build/bin/lldb-dap+0x94705) llvm#24 0x000062735c2ed0c7 main (/home/sergei/llvm-project/build/bin/lldb-dap+0x290c7) llvm#25 0x00007eaa6aa2a1ca __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3 ``` As far as I understand default constuctors should be covered by fuzzing tests, so I don't know how to write test for that patch.
WuXintong123
pushed a commit
that referenced
this pull request
Jun 12, 2026
…ructions (llvm#185170) We currently emit `movi`+`ext` instructions when generating code for shuffle slides of a 64-bit vector left/right and fill it with zeros. This patch optimizes these patterns to use a single `ushr`/`shl` instruction instead. Example: ```llvm define <8 x i8> @slide_left(<8 x i8> %v) { %r = shufflevector <8 x i8> %v, <8 x i8> zeroinitializer, <8 x i32> <i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 8> ret <8 x i8> %r } ``` Before, we generate: ``` movi v1.2d, #0 ext v0.8b, v0.8b, v1.8b, #1 ``` Now: ``` ushr d0, d0, #8 ``` Fixes: llvm#183398 Alive2 proof: https://alive2.llvm.org/ce/z/QaW5CQ --------- Signed-off-by: Dibri Nsofor <dibrinsofor@gmail.com>
WuXintong123
pushed a commit
that referenced
this pull request
Jun 24, 2026
…203854) ### Summary On ARM/Thumb2, a saturating clamp to a signed range that is not centered on zero is *not* matched to `ssat`, even though it can be potentially matched to `ssat`. The backend instead emits a long explicit compare/select clamp. This pattern is extremely common in quantized ML code: an int8 requantize is `clamp(accumulator + output_zero_point, -128, 127)`, and whenever the output zero_point != 0, the instruction count regress from one ssat to ~10 instructions. The root cause is that InstCombine canonically **sinks the constant out of the min/max** — `clamp(X + C, -128, 127)` becomes `clamp(X, -128-C, 127-C) + C` — and the backend's SSAT matcher (`PerformMinMaxToSatCombine`) only handles a clamp whose bounds already form a saturation range. The offset of the form (`[-128-C, 127-C]`, width 256 = 2⁸) falls through to a generic clamp. #### Reproducer ```c #include <stdint.h> int8_t requant_offset(int32_t acc) { // output zero-point = 96 int32_t v = (acc >> 8) + 96; if (v < -128) v = -128; if (v > 127) v = 127; return (int8_t)v; } int8_t requant_zero(int32_t acc) { // output zero-point = 0 (for contrast) int32_t v = (acc >> 8); if (v < -128) v = -128; if (v > 127) v = 127; return (int8_t)v; } ``` ``` clang -O2 --target=thumbv7em-none-eabihf -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -S issue.c ``` **Actual** `requant_offset` (zero-point 96): ```asm asrs r1, r0, #8 cmn.w r1, llvm#224 mvn r1, llvm#223 it gt asrgt r1, r0, #8 cmp r1, llvm#31 it ge movge r1, llvm#31 add.w r0, r1, llvm#96 sxtb r0, r0 ``` `requant_zero` (zero-point 0): ```asm ssat r0, #8, r0, asr #8 ``` #### Expected `requant_offset` should select `ssat`, e.g.: ```asm movs r1, llvm#96 add.w r0, r1, r0, asr #8 ssat r0, #8, r0 subs r0, llvm#96 ``` #### Why this is sound A clamp whose width (hi − lo + 1) is a power of two is just an `ssat` shifted off zero by constant C. ``` clamp(X, lo, hi) == ssat_k(X − C) + C, C = lo + 2^(k-1) ``` e.g. `clamp(X, −224, 31)` == `clamp(X+96, (-225+96), (31+96)) - 96` == `ssat8(X + 96) − 96` Assisted-by: Claude
WuXintong123
pushed a commit
that referenced
this pull request
Jun 29, 2026
`Evaluate_DW_OP_deref` validated that the dereference size was `<= 8` but not that it was non-zero. The DWARF expression evaluator parses untrusted operands, so a `DW_OP_deref_size` with size operand `0` is reachable (it is hit by the lldb-dwarf-expression-fuzzer). A zero dereference size flows into `DerefSizeExtractDataHelper`, which constructs a `DataExtractor` with `addr_size == 0` and aborts on its assertion. The unit test that feeds `DW_OP_lit0, DW_OP_deref_size, 0x00` shows the crash: ``` [ RUN ] DWARFExpressionMockProcessTest.DW_OP_deref_size_zero Assertion failed: (addr_size >= 1 && addr_size <= 8), function DataExtractor, file DataExtractor.cpp, line 134. #8 DataExtractor::DataExtractor(...) #11 DWARFExpression::Evaluate(...) ``` Reject a zero dereference size with an error, alongside the existing `size > 8` check. Adds `DWARFExpressionMockProcessTest.DW_OP_deref_size_zero`, which aborts on the assertion above without the fix.
WuXintong123
pushed a commit
that referenced
this pull request
Jul 1, 2026
…lvm#191275)" (llvm#206816) This reverts commit 0f51760. A test fails with the commit (llvm#191275 (comment)): ``` Traceback (most recent call last): File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 596, in test_python_source_frames self.assertNotIn("0xffffffffffffffff", output.lower()) AssertionError: '0xffffffffffffffff' unexpectedly found in "* thread #2, name = 'a.out', stop reason = breakpoint 1.1\n * frame #0: compute_fibonacci at python_helper.py:7 [synthetic]\n frame #1: process_data at python_helper.py:16 [synthetic]\n frame #2: main at python_helper.py:27 [synthetic]\n frame #3: 0x0000badc2de81358 a.out`thread_func(thread_num=0) at main.cpp:44:13\n frame #4: 0x0000badc2de81f9c a.out`void std::__invoke_impl<void, void (*)(int), int>((null)=__invoke_other @ 0x0000f1555ebae74f, __f=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:61:14\n frame #5: 0x0000badc2de81f18 a.out`std::__invoke_result<void (*)(int), int>::type std::__invoke<void (*)(int), int>(__fn=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:96:14\n frame #6: 0x0000badc2de81ee4 a.out`void std::thread::_invoker<std::tuple<void (*)(int), int>>::_m_invoke<0ul, 1ul>(this=0x0000badc66845eb8, (null)=_index_tuple<0ul, 1ul> @ 0x0000f1555ebae7af) at std_thread.h:259:13\n frame #7: 0x0000badc2de81e98 a.out`std::thread::_invoker<std::tuple<void (*)(int), int>>::operator()(this=0x0000badc66845eb8) at std_thread.h:266:11\n frame #8: 0x0000badc2de81d70 a.out`std::thread::_state_impl<std::thread::_invoker<std::tuple<void (*)(int), int>>>::_m_run(this=0xffffffffffffffff) at std_thread.h:211:13\n frame #9: 0x0000f1555ef029cc libstdc++.so.6`___lldb_unnamed_symbol_d29b0 + 28\n frame #10: 0x0000f1555ec30398 libc.so.6`___lldb_unnamed_symbol_800c0 + 728\n frame #11: 0x0000f1555ec99e9c libc.so.6`___lldb_unnamed_symbol_e9e90 + 12\n" ``` I don't know why this test fails with the PR, but I don't have time to fix it now, so revert it to unblock CI. The backtrace was ``` frame #0: compute_fibonacci at python_helper.py:7 [synthetic] frame #1: process_data at python_helper.py:16 [synthetic] frame #2: main at python_helper.py:27 [synthetic] frame #3: 0x0000badc2de81358 a.out`thread_func(thread_num=0) at main.cpp:44:13 frame #4: 0x0000badc2de81f9c a.out`void std::__invoke_impl<void, void (*)(int), int>((null)=__invoke_other @ 0x0000f1555ebae74f, __f=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:61:14 frame #5: 0x0000badc2de81f18 a.out`std::__invoke_result<void (*)(int), int>::type std::__invoke<void (*)(int), int>(__fn=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:96:14 frame #6: 0x0000badc2de81ee4 a.out`void std::thread::_invoker<std::tuple<void (*)(int), int>>::_m_invoke<0ul, 1ul>(this=0x0000badc66845eb8, (null)=_index_tuple<0ul, 1ul> @ 0x0000f1555ebae7af) at std_thread.h:259:13 frame #7: 0x0000badc2de81e98 a.out`std::thread::_invoker<std::tuple<void (*)(int), int>>::operator()(this=0x0000badc66845eb8) at std_thread.h:266:11 frame #8: 0x0000badc2de81d70 a.out`std::thread::_state_impl<std::thread::_invoker<std::tuple<void (*)(int), int>>>::_m_run(this=0xffffffffffffffff) at std_thread.h:211:13 frame #9: 0x0000f1555ef029cc libstdc++.so.6`___lldb_unnamed_symbol_d29b0 + 28 frame #10: 0x0000f1555ec30398 libc.so.6`___lldb_unnamed_symbol_800c0 + 728 frame #11: 0x0000f1555ec99e9c libc.so.6`___lldb_unnamed_symbol_e9e90 + 12 ``` This contains 0xffffffffffffffff in frame 8.
WuXintong123
pushed a commit
that referenced
this pull request
Jul 3, 2026
… movemask (llvm#199081) The existing lowering in vectorToScalarBitmask() creates a 1 bit per lane movemask using a powers of 2 reduction (and+addv with a constant pool entry). This patch adds a DAG combine on ISD::CTTZ that recognizes cttz(bitcast <N x i1> to iN) and produces a compressed movemask with shrn (for i8 lanes) or xtn (for wider lanes) then runs scalar cttz on a 64- or 128-bit value. Dividing by bits per lane gives the lane index. Supports lane counts {2, 4, 8, 16, 32} (one or two NEON registers) For the example in the issue (`<16 x i8> -> i16`): Before: ```asm adrp x8, .LCPI0_0 cmlt v0.16b, v0.16b, #0 ldr q1, [x8, :lo12:.LCPI0_0] and v0.16b, v0.16b, v1.16b ext v1.16b, v0.16b, v0.16b, #8 zip1 v0.16b, v0.16b, v1.16b addv h0, v0.8h fmov w8, s0 orr w8, w8, #0x10000 rbit w8, w8 clz w0, w8 ret ``` After: ```asm cmlt v0.16b, v0.16b, #0 shrn v0.8b, v0.8h, #4 fmov x8, d0 rbit x8, x8 clz x8, x8 lsr x0, x8, #2 ret ``` Also created a new test file with 24 functions covering both endianness - 7 basic widths (`<16 x i8>` down through `<2 x i32>`) - 4 wider cases that span two NEON registers (`<32 x i8>` etc) - 2 narrow cases that get sext'd up to fit one register - 2 cases where the bitcast has two users - 4 alternative comparison operators (`eq`, `ne`, etc) - 1 `cttz` with `is_zero_undef=true` - 4 negative tests that bails for unsupported shapes Fixes llvm#186295
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.