Repository navigation
Bazel 52dfcab327fe959074563603b6ebaaed314e9677 - #1
Closed
googlewalt wants to merge 41 commits into
Closed
googlewalt wants to merge 41 commits into
googlewalt wants to merge 41 commits into
Conversation
This patch moves ValueImpl and ValueLocker to ValueObject.{h,cpp}. This follows the example set in TypeImpl/SBType, where we have something that SBType uses internally that needs to be exposed in the layer below. In this case, SBValue uses ValueImpl, which wraps ValueObject. The wrapper helps avoid bugs, so we want to keep it, but the script interpreter needs to use it and said interpreter is conceptually *below* the SB layer...which means we can't use methods on SBValue.
This patch is purely the code motion part of that, future patches will actually make use of this moved code.
This patch adds the coreFilePath, if applicable, to the target statistics for LLDB. My primary motivation here is sanity check user reports when they say I had an issue with a specific corefile and then validating it was in fact that specifies corefile, as right now there is no guaruntee the filename and the process/target name will be the same.
…able (llvm#177703) Context: llvm#176001 (comment) When we're hoisting a spill to another block, and storing one of its sibling values there instead, we need to make sure all sub ranges of that sibling value is alive at the insertion point. Otherwise, we might accidentally store compromised subranges values back to the spill slot.
…ge. (llvm#178574) This patch adds support for: - PyObject -> SBValueList (which was surprisingly not there before!) - PyObject -> SBValue - SBValue -> ValueObjectSP using the ScriptInterpreter These three are the main remaining plumbing changes necessary before we can get to the meat of actually using ScriptedFrame to provide values to the printer/etc. Future patches build off this change in order to allow ScriptedFrames to provide variables and get values for variable expressions.
…ion api (llvm#177676) ## Description Contribution to this topic [Rich Disassembler for LLDB](https://discourse.llvm.org/t/rich-disassembler-for-lldb/76952), this part. ``` The rich disassembler output should be exposed as structured data and made available through LLDB’s scripting API so more tooling could be built on top of this ``` ---- This pr replaces llvm#174847 As was suggested in [this comment](llvm#174847 (comment)), implement access to variable annotations from `SBInstruction` class itself. Notes: - ✅ did run black formatter on the python file; ## Testing Run test with ```sh ./build/bin/lldb-dotest -v -p TestVariableAnnotationsDisassembler.py lldb/test/API/functionalities/disassembler-variables ``` all tests (9 existing + 1 newly added) are passing <details> <summary>screenshot 2026-01-23</summary> build from the latest commit 08f0073 <img width="1506" height="562" alt="image" src="https://github.com/user-attachments/assets/69516353-3432-47df-ae45-c40b51ec14c4" /> </details> <details> <summary>screenshot 2026-01-29</summary> build from the latest commit f48a1a2 <img width="1232" height="740" alt="image" src="https://github.com/user-attachments/assets/9d104ce6-36c3-430b-98fe-f028f83a6b6d" /> </details> --------- Signed-off-by: Nikita B <n2h9z4@gmail.com>
…to scalar identity/bswap, NFC
…77507) This patch changes the run lines for cosh, exp, normalize overload test to use -O1 instead of -disable-llvm-passes and rewrite the tests to actually look at the whole function. This work is part of llvm#138016. --------- Co-authored-by: Joao Saffran <jderezende@microsoft.com>
…7657) This patch changes the run lines for frac, tanh, degrees overload test to use -O1 instead of -disable-llvm-passes and rewrite the tests to actually look at the whole function. This work is part of llvm#138016.
This patch changes the run lines for log, asin, acos overload test to use -O1 instead of -disable-llvm-passes and rewrite the tests to actually look at the whole function. This work is part of llvm#138016.
) This patch changes the run lines for step, isinf, rsqrt overload test to use -O1 instead of -disable-llvm-passes and rewrite the tests to actually look at the whole function. This work is part of llvm#138016.
This patch changes the run lines for log2, tan overload test to use -O1 instead of -disable-llvm-passes and rewrite the tests to actually look at the whole function. This work is part of llvm#138016.
This patch changes the run lines for atan, sin, sqrt overload test to use -O1 instead of -disable-llvm-passes and rewrite the tests to actually look at the whole function. This work is part of llvm#138016.
…8508) This patch changes the run lines for round, trunc, floor overload test to use -O1 instead of -disable-llvm-passes and rewrite the tests to actually look at the whole function. This work is part of llvm#138016.
This PR adds the WavePrefixCountBits function to HLSL, including spirv and DXIL code generation. Fixes llvm#99171
llvm#178441) The code assumed that taking the lexical parent decl context of a node and traversing it will eventually visit the node itself. While this is certeanly true for most AST constructs, template specializations (aka. instantiations) might inject their AST to surprising lexical parents, depending on when they get instantiated. This means that just taking the lexical parent of a template specialization might land us on some AST node that won't contain (thus visit) the definition, and consequently, miss the Suppress attribute... To fix this, we must take special care for template specializations. For a regular instantiation select the primary template (that has the definition). For an instantiation coming from a partial specialization, pretend if it was the partial specialization instead. Once we canonicalize to the primary template/partial specialization definition, the usual "walk the lexical parents" logic covers the rest as usual. Assisted-by: claude rdar://168941095
When DetectReplMode is called without a valid frame, we cannot check if an expression refers to a variable in scope. This avoids unnecessary checks when completing expressions.
This PR adds the combine rule `fold (add x, shl(0 - y, n)) -> sub(x, shl(y, n))` to GlobalISel, corresponding to an existing SelectionDAG combine in [DAGCombiner::visitADDLikeCommutative](https://github.com/llvm/llvm-project/blame/fcba3040107944604904aeb146c26ec0628160f4/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#L3367). Co-authored-by: Sarah Kuhn <sarahlinhkuhn@gmail.com> --------- Co-authored-by: Sarah Kuhn <sarahlinhkuhn@gmail.com> Co-authored-by: Luisa Cicolini <48860705+luisacicolini@users.noreply.github.com>
…lvm#166030) This change improves memset code generation for non-zero values on AArch64 by using NEON's DUP instruction instead of the less efficient multiplication with 0x01010101 pattern. For small sizes, the value is extracted from a larger DUP. For non-power-of-two sizes, overlapping stores are used in some cases. TargetLowering::findOptimalMemOpLowering is modified to allow explicitly specifying the size of the constant in cases where the constant is larger than the store operations. Fixes llvm#165949
…lvm#178744) I suspect this was here to prevent a trailing comma. If we actually reach this byte in isel, it will be treated as OPC_Scope not a terminator.
…llvm#178340) We also get some i32->i64 promotion for CLMULH. The DAGCombiner change is to prevent an infinite loop from that. Test file was rewritten to cover all types and split between clmul and clmulh. I added a couple masked tests to show that VectorPeephole works. The test outputs were already large so I didn't want to add more than a couple.
…path="" (llvm#178743) Some tools pass external_symbolizer_path="", which means it is not expected to have any symbolizers in the list at the point we inserted a (Darwin-only) warning. This moves the symbolizer warning into ChooseExternalSymbolizer, after the external_symbolizer_path="" case has been handled. rdar://169137614
…178107) This allows a common, memory-safe form of memset, `memset(&x, val, sizeof(x))`. There are potentially other safe forms that we can allow in later PRs. The tests cover some of the possible cases.
…part 11) (llvm#178577) Tests converted from test/Lower: dense-attributed-array.f90, goto-statement.f90, infinite_loop.f90, return-statement.f90, stop-statement.f90
Remove pass initialization from pass constructor for GCEmptyBasicBlocksLegacy pass.
…llvm#178754) This change updates addOptionalGlobalSymbol to match addOptionalDataSymbol. The effected tests here are all using the `--export-all` flag.
…m#178529) This PR continues work from llvm#178290. Cleaned up LLVM utilities in IRCore.cpp: `enumerate`, `zip`, `ArrayRef`, `hash_value`.
…#178260) Adds CIR `ClearCacheOp` and lowers `__builtin___clear_cache` through CIR to the LLVM `llvm.clear_cache` intrinsic. Includes codegen + lowering support and a test.
…78118) The `OpWithOffsetSizesAndStridesConstantArgumentFolder` pattern for tensor.extract_slice was incorrectly using `inferCanonicalRankReducedResultType()` to compute the result type after folding constant offsets. This function infers a canonical rank reduction (dropping the first N unit dimensions), which breaks when the original operation used a non-canonical rank reduction. This change is similar to the existing correct behavior in `SubViewReturnTypeCanonicalizer` for `memref.subview`. For example, extracting `tensor<1x4xf16>` from `tensor<1x1x8x1xf16>` by dropping dims 0 and 3 would incorrectly produce tensor<4x1xf16> (canonical: drop dims 0 and 1). --------- Signed-off-by: Ian Wood <ianwood@u.northwestern.edu>
This adds a document describing the implementation of LLVM IR generation for exceptions and C++ cleanup handling. This will be used as a point of reference for future CIR exception handling design work. This document was generated using AI, with some manual modifications afterwards.
…78562) Follow the style of other dialects by having a distiinct .td file for each category of thing (type, attribdut, operation, enum) generated for the AMDGPU dialect. Nothing has changed, but a lot of things have been copy-pasted.
googlewalt
pushed a commit
that referenced
this pull request
Feb 12, 2026
…8306) In FreeBSD, allproc is a prepend list and new processes are appended at head. This results in reverse pid order, so we first need to order pid incrementally then print threads according to the correct order. Before: ``` Process 0 stopped * thread #1: tid = 101866, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff8015882f780, flags=259) at sched_ule.c:2448:26, name = '(pid 12991) dtrace' thread llvm#2: tid = 101915, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff80158825780, flags=259) at sched_ule.c:2448:26, name = '(pid 11509) zsh' thread llvm#3: tid = 101942, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff80142599000, flags=259) at sched_ule.c:2448:26, name = '(pid 11504) ftcleanup' thread llvm#4: tid = 101545, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff80131898000, flags=259) at sched_ule.c:2448:26, name = '(pid 5599) zsh' thread llvm#5: tid = 100905, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff80131899000, flags=259) at sched_ule.c:2448:26, name = '(pid 5598) sshd-session' thread llvm#6: tid = 101693, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff8015886e780, flags=259) at sched_ule.c:2448:26, name = '(pid 5595) sshd-session' thread llvm#7: tid = 101626, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801588be000, flags=259) at sched_ule.c:2448:26, name = '(pid 5592) sh' ... ``` After: ``` (lldb) thread list Process 0 stopped * thread #1: tid = 100000, 0xffffffff80bf9322 kernel`sched_switch(td=0xffffffff81abe840, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel' thread llvm#2: tid = 100035, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d9780, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_0' thread llvm#3: tid = 100036, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d9000, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_1' thread llvm#4: tid = 100037, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d8780, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_2' thread llvm#5: tid = 100038, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d8000, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_3' thread llvm#6: tid = 100039, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d7780, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_4' thread llvm#7: tid = 100040, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d7000, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_5' ... ``` Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
googlewalt
pushed a commit
that referenced
this pull request
Mar 27, 2026
…e edge case (llvm#188590) llvm#186966 was reverted because the test case triggered a use-of-uninitialized-memory (https://lab.llvm.org/buildbot/#/builders/94/builds/16379), due to the include directive omitting a trailing newline. This patch adds a minor fix to avoid the use-of-uninitialized-memory, and deliberately re-adds the test case sans trailing newline for regression testing. MSan report prior to this fix: ``` @@@BUILD_STEP sanitizer logs: stage2/msan_track_origins check@@@ ==clang-scan-deps==616960==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x5555599c3300 in isAnnotation /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/include/clang/Lex/Token.h:131:38 #1 0x5555599c3300 in setLength /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/include/clang/Lex/Token.h:152:13 llvm#2 0x5555599c3300 in clang::Lexer::FormTokenWithChars(clang::Token&, char const*, clang::tok::TokenKind) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/include/clang/Lex/Lexer.h:644:12 llvm#3 0x5555599cf895 in clang::Lexer::LexEndOfFile(clang::Token&, char const*) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/Lexer.cpp:3166:5 llvm#4 0x555559bb229b in clang::Preprocessor::Lex(clang::Token&) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/Preprocessor.cpp:916:11 llvm#5 0x555559aa5365 in __invoke<void (clang::Preprocessor::*&)(clang::Token &), clang::Preprocessor *, clang::Token &> /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/libcxx_install_msan_track_origins/include/c++/v1/__type_traits/invoke.h:90:27 llvm#6 0x555559aa5365 in invoke<void (clang::Preprocessor::*&)(clang::Token &), clang::Preprocessor *, clang::Token &> /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/libcxx_install_msan_track_origins/include/c++/v1/__functional/invoke.h:29:10 llvm#7 0x555559aa5365 in operator()<void (clang::Preprocessor::*)(clang::Token &)> /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/PPDirectives.cpp:470:5 llvm#8 0x555559aa5365 in clang::Preprocessor::CheckEndOfDirective(llvm::StringRef, bool, llvm::SmallVectorImpl<clang::Token>*) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/PPDirectives.cpp:478:5 llvm#9 0x555559ab96b5 in clang::Preprocessor::HandleIncludeDirective(clang::SourceLocation, clang::Token&, clang::detail::SearchDirIteratorImpl<true>, clang::FileEntry const*) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/PPDirectives.cpp:2205:7 ... ```
googlewalt
pushed a commit
that referenced
this pull request
Jun 22, 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, llvm#8 ``` Fixes: llvm#183398 Alive2 proof: https://alive2.llvm.org/ce/z/QaW5CQ --------- Signed-off-by: Dibri Nsofor <dibrinsofor@gmail.com>
googlewalt
pushed a commit
that referenced
this pull request
Jun 22, 2026
…m#204601) When creating the new intrinsic declaration, use the correct pointer argument (arg #1) from the existing call. Currently, we use arg #0 (size) and end up creating an invalid intrinsic declaration. However, later on we do not use this declaration directly and instead call `CreateLifetimeStart` or `CreateLifetimeEnd` IRBuilder functions that end up creating valid intrinsic declarations. The net result is that we are left with a stray unused invalid declaration. Fix this issue by creating the intrinsic with the right pointer argument type.
googlewalt
pushed a commit
that referenced
this pull request
Aug 3, 2026
…che images (llvm#207448) `ObjectFileMachO::ParseSymtab`, when handling a local shared cache image (`MH_DYLIB_IN_CACHE` set and not read from memory), unconditionally called `linkedit_section_sp->GetFileOffset()` to slide the load command offsets. If the Mach-O has no `__LINKEDIT` segment, `FindSectionByName` returns a `null` SectionSP, and this is a member call on a null pointer (caught by UBSan; crashes in release builds). ``` * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x68) * frame #0: 0x0000000100121ff0 ObjectFileMachOTests`lldb_private::Section::GetFileOffset(this=0x0000000000000000) const at Section.h:181:49 [opt] [inlined] frame #1: 0x0000000100121ff0 ObjectFileMachOTests`ObjectFileMachO::ParseSymtab(this=0x00000001055616b0, symtab= 0x000000016fdfe988) at ObjectFileMachO.cpp:2353:59 [opt] ``` Guard the shared-cache slide branch with a null check on `linkedit_section_sp`, matching the existing guard used on the in-memory path. Found by lldb-target-fuzzer. --------- Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
googlewalt
pushed a commit
that referenced
this pull request
Aug 3, 2026
…lvm#212759) I see the following ``` anutosh491@Anutoshs-MacBook-Air llvm-project % cat /private/tmp/wasm-scalable-shift-cost.ll define <vscale x 4 x i32> @shift(<vscale x 4 x i32> %x, <vscale x 4 x i32> %amount) { %result = shl <vscale x 4 x i32> %x, %amount ret <vscale x 4 x i32> %result } anutosh491@Anutoshs-MacBook-Air llvm-project % build-assert/bin/opt \ -mtriple=wasm32-unknown-unknown \ -mattr=+simd128 \ -passes='print<cost-model>' \ -disable-output \ /private/tmp/wasm-scalable-shift-cost.ll Printing analysis 'Cost Model Analysis' for function 'shift': Cost Model: Assertion failed: (isa<To>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file Casting.h, line 572. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug. Stack dump: 0. Program arguments: build-assert/bin/opt -mtriple=wasm32-unknown-unknown -mattr=+simd128 -passes=print<cost-model> -disable-output /private/tmp/wasm-scalable-shift-cost.ll 1. Running pass "function(print<cost-model>)" on module "/private/tmp/wasm-scalable-shift-cost.ll" 2. Running pass "print<cost-model>" on function "shift" #0 0x0000000105b7a56c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x102f6256c) #1 0x0000000105b78248 llvm::sys::RunSignalHandlers() (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x102f60248) llvm#2 0x0000000105b7b170 SignalHandler(int, __siginfo*, void*) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x102f63170) llvm#3 0x000000018b5f7744 (/usr/lib/system/libsystem_platform.dylib+0x1804fb744) llvm#4 0x000000018b5ed8d8 (/usr/lib/system/libsystem_pthread.dylib+0x1804f18d8) llvm#5 0x000000018b4f4644 (/usr/lib/system/libsystem_c.dylib+0x1803f8644) llvm#6 0x000000018b4f38a0 (/usr/lib/system/libsystem_c.dylib+0x1803f78a0) llvm#7 0x0000000104036ddc llvm::BasicTTIImplBase<llvm::WebAssemblyTTIImpl>::getArithmeticInstrCost(unsigned int, llvm::Type*, llvm::TargetTransformInfo::TargetCostKind, llvm::TargetTransformInfo::OperandValueInfo, llvm::TargetTransformInfo::OperandValueInfo, llvm::ArrayRef<llvm::Value const*>, llvm::Instruction const*) const (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x10141eddc) llvm#8 0x000000010403b0ac llvm::TargetTransformInfoImplCRTPBase<llvm::WebAssemblyTTIImpl>::getInstructionCost(llvm::User const*, llvm::ArrayRef<llvm::Value const*>, llvm::TargetTransformInfo::TargetCostKind) const (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x1014230ac) llvm#9 0x00000001049162c8 llvm::TargetTransformInfo::getInstructionCost(llvm::User const*, llvm::ArrayRef<llvm::Value const*>, llvm::TargetTransformInfo::TargetCostKind) const (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x101cfe2c8) llvm#10 0x00000001058d90b4 llvm::TargetTransformInfo::getInstructionCost(llvm::User const*, llvm::TargetTransformInfo::TargetCostKind) const (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x102cc10b4) llvm#11 0x000000010468a368 getCost(llvm::Instruction&, llvm::TargetTransformInfo::TargetCostKind, llvm::TargetTransformInfo&) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x101a72368) llvm#12 0x0000000104689dd4 llvm::CostModelPrinterPass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x101a71dd4) llvm#13 0x0000000105186554 llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x10256e554) llvm#14 0x000000010518a680 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x102572680) llvm#15 0x0000000105185418 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x10256d418) llvm#16 0x0000000106127cb0 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::PassPlugin>, llvm::ArrayRef<std::__1::function<void (llvm::PassBuilder&)>>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool, bool) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x10350fcb0) llvm#17 0x0000000106131eac optMain (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x103519eac) llvm#18 0x000000018b22fe00 zsh: abort build-assert/bin/opt -mtriple=wasm32-unknown-unknown -mattr=+simd128 ```
googlewalt
pushed a commit
that referenced
this pull request
Aug 3, 2026
```
define <8 x half> @insert_v8f16(<8 x half> %v, half %x) {
%r = insertelement <8 x half> %v, half %x, i32 3
ret <8 x half> %r
}
```
```
llc \
-mtriple=wasm32-unknown-unknown \
-mattr=+simd128,+fp16 \
-o /dev/null \
/private/tmp/wasm-v8f16-insert-only.ll
```
Would lead to
```
Initial selection DAG: %bb.0 'insert_v8f16:'
SelectionDAG has 10 nodes:
t0: ch,glue = EntryToken
t2: v8f16 = WebAssemblyISD::ARGUMENT TargetConstant:i32<0>
t4: i32 = WebAssemblyISD::ARGUMENT TargetConstant:i32<1>
t5: i16 = truncate t4
t6: f16 = bitcast t5
t8: v8f16 = insert_vector_elt t2, t6, Constant:i32<3>
t9: ch = WebAssemblyISD::RETURN t0, t8
Soft promote half operand 1:
t8: v8f16 = insert_vector_elt t2, t6, Constant:i32<3>
SoftPromoteHalfOperand Op #1:
t8: v8f16 = insert_vector_elt t2, t6, Constant:i32<3>
LLVM ERROR: Do not know how to soft promote this operator's operand!
```
googlewalt
pushed a commit
that referenced
this pull request
Aug 10, 2026
…ical blocks (llvm#215036) Merging identical blocks threads their differing values through the predecessors' terminators as new successor operands, but the only legality question asked of a predecessor was whether its terminator implements `BranchOpInterface` (`ableToUpdatePredOperands`). The transform's implicit assumption is that such a terminator can forward operands of **any** type — false for dialects whose branch ops constrain successor operand types. The LLVM dialect terminators declare theirs as `Variadic<LLVM_Type>`, so merging two blocks that differ in, say, an index-typed operand rewrote a verifying `llvm.cond_br` into one that no longer verifies. Reproducer (mixed-dialect IR of the kind a progressive lowering/raising pipeline carries), via `mlir-opt -pass-pipeline='builtin.module(func.func(canonicalize{region-simplify=aggressive}))'`: ```mlir func.func @f(%m: memref<4xf32>, %c: i1) { %f = arith.constant 1.0 : f32 %i0 = arith.constant 0 : index %i1 = arith.constant 1 : index llvm.cond_br %c, ^a, ^b ^a: memref.store %f, %m[%i0] : memref<4xf32> llvm.return ^b: memref.store %f, %m[%i1] : memref<4xf32> llvm.return } ``` previously produced ``` error: 'llvm.cond_br' op operand #1 must be variadic of LLVM dialect-compatible type, but got 'index' note: see current operation: "llvm.cond_br"(%arg1, %1, %2)[^bb1, ^bb1] ... ``` i.e. the transform manufactured IR that cannot verify. (Any greedy driver running at `GreedySimplifyRegionLevel::Aggressive` — the `applyPatternsGreedily` default — hits this; downstream we currently work around it by dropping to `Normal`.) This adds `mayForwardTypeToSuccessor(unsigned index, Type type)` to `BranchOpInterface`, default permissive, and makes block merging refuse a cluster when any predecessor terminator refuses any of the would-be block argument types. The LLVM dialect terminators (`br`, `cond_br`, `switch`, `invoke`, `indirectbr`) override it with `isCompatibleType`. The new test pins both directions: the index-typed merge is refused, an i32-typed merge through `llvm.cond_br` still happens. Assisted-by: Claude
googlewalt
pushed a commit
that referenced
this pull request
Aug 13, 2026
…ction of a mask (llvm#215187) foldPartialReduceAdd synthesises the reduction's multiplier at the operand's type. At i1 a splat of 1 is all ones, which sign extends to -1, so the signed forms compute (-1) x (-1) = +1 per lane and sum to +n where sum(sext(mask)) must be -n. ```llvm %cmp = icmp eq <16 x i8> %a, %b %sext = sext <16 x i1> %cmp to <16 x i32> %r = call <4 x i32> @llvm.vector.partial.reduce.add(<4 x i32> %acc, <16 x i32> %sext) ``` -mattr=+neon sums to -n: ``` cmeq v1.16b, v1.16b, v2.16b sshll v2.8h, v1.8b, #0 sshll2 v1.8h, v1.16b, #0 saddw v0.4s, v0.4s, v2.4h saddw2 v0.4s, v0.4s, v2.8h saddw v0.4s, v0.4s, v1.4h saddw2 v0.4s, v0.4s, v1.8h ``` -mattr=+neon,+dotprod sums to +n: ``` movi v3.2d, #0xffffffffffffffff cmeq v1.16b, v1.16b, v2.16b sdot v0.4s, v1.16b, v3.16b ``` This patch extends i1 masks to the promoted type before the multiplier is built. That gives `movi v3.16b, #1` and the dot product path agrees with the expansion. Part of llvm#204897.
googlewalt
pushed a commit
that referenced
this pull request
Aug 21, 2026
I see the following
```
anutosh491@Anutoshs-MacBook-Air llvm-project % cat /private/tmp/wasm-f16-select.ll
define <8 x half> @select_v8f16(i1 %cond, <8 x half> %a, <8 x half> %b) {
%result = select i1 %cond, <8 x half> %a, <8 x half> %b
ret <8 x half> %result
}
```
```
anutosh491@Anutoshs-MacBook-Air llvm-project % build-assert/bin/llc \
-mtriple=wasm32-unknown-unknown \
-mattr=+simd128,+fp16 \
-o /dev/null \
/private/tmp/wasm-f16-select.ll
LLVM ERROR: Cannot select: t8: v8f16 = select t12, t4, t6
t12: i32 = and t2, Constant:i32<1>
t2: i32 = WebAssemblyISD::ARGUMENT TargetConstant:i32<0>
t4: v8f16 = WebAssemblyISD::ARGUMENT TargetConstant:i32<1>
t6: v8f16 = WebAssemblyISD::ARGUMENT TargetConstant:i32<2>
In function: select_v8f16
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug.
Stack dump:
0. Program arguments: build-assert/bin/llc -mtriple=wasm32-unknown-unknown -mattr=+simd128,+fp16 -o /dev/null /private/tmp/wasm-f16-select.ll
1. Running pass 'Function Pass Manager' on module '/private/tmp/wasm-f16-select.ll'.
2. Running pass 'WebAssembly Instruction Selection' on function '@select_v8f16'
#0 0x0000000103c6852c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1030e852c)
#1 0x0000000103c66208 llvm::sys::RunSignalHandlers() (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1030e6208)
llvm#2 0x0000000103c69130 SignalHandler(int, __siginfo*, void*) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1030e9130)
llvm#3 0x000000018b5f7744 (/usr/lib/system/libsystem_platform.dylib+0x1804fb744)
llvm#4 0x000000018b5ed8d8 (/usr/lib/system/libsystem_pthread.dylib+0x1804f18d8)
llvm#5 0x000000018b4f4644 (/usr/lib/system/libsystem_c.dylib+0x1803f8644)
llvm#6 0x0000000103bbc0b4 llvm::report_fatal_error(llvm::Twine const&, bool) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x10303c0b4)
llvm#7 0x0000000103af91b8 llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f791b8)
llvm#8 0x0000000103af813c llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int, unsigned char const*) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f7813c)
llvm#9 0x0000000101f66b78 (anonymous namespace)::WebAssemblyDAGToDAGISel::Select(llvm::SDNode*) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1013e6b78)
llvm#10 0x0000000103aee46c llvm::SelectionDAGISel::DoInstructionSelection() (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f6e46c)
llvm#11 0x0000000103aed400 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f6d400)
llvm#12 0x0000000103aeb4b4 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f6b4b4)
llvm#13 0x0000000103ae8ba8 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f68ba8)
llvm#14 0x0000000103ae6cd8 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f66cd8)
llvm#15 0x0000000102b71d28 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x101ff1d28)
llvm#16 0x0000000103096900 llvm::FPPassManager::runOnFunction(llvm::Function&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102516900)
llvm#17 0x000000010309cc00 llvm::FPPassManager::runOnModule(llvm::Module&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x10251cc00)
llvm#18 0x0000000103097174 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102517174)
llvm#19 0x0000000100b880a4 main (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1000080a4)
llvm#20 0x000000018b22fe00
zsh: abort build-assert/bin/llc -mtriple=wasm32-unknown-unknown -mattr=+simd128,+fp16 -o
```
googlewalt
pushed a commit
that referenced
this pull request
Aug 21, 2026
…list (llvm#216847) `Thread::ClearStackFrames` keeps the previous public frame list as the predecessor of the next unwinder list. When a scripted frame provider is registered, that public list is a `SyntheticStackFrameList` holding `BorrowedStackFrames`, and the unwinder list's merge step reuses a predecessor frame whenever the stack IDs match, so it adopted frames belonging to the provider's list. `UpdatePreviousFrameFromCurrentFrame` refreshes `StackFrame::m_frame_index`, but `BorrowedStackFrame::GetFrameIndex()` returns its own `m_new_frame_index`, which supersedes it. The adopted frame keeps reporting its index from the previous stop, so once the stack grows the backtrace stops counting up: ``` frame #1: middle frame #1: main frame llvm#2: start ``` Such a frame also delegates its stack ID, register context and symbol context to a frame from the previous stop that the merge never refreshes, so it could report stale state as well. In the backtrace above, main also lost its source location. When the merge finds a matching predecessor frame that is a `BorrowedStackFrame`, keep the freshly unwound frame instead of adopting it. Only providers create BorrowedStackFrames, so this never drops a frame the unwinder built itself. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
googlewalt
pushed a commit
that referenced
this pull request
Aug 21, 2026
…llvm#217377) Inline frames share the concrete frame's PC, so they share its address convention. Hardcoding false made GetFrameCodeAddressForSymbolication look up PC-1, resolving sc.symbol to the preceding symbol when the PC is a function's first instruction. StackFrameListTest checks that every frame sharing the concrete frame's PC reports the same address from GetFrameCodeAddressForSymbolication. Frame 1 reports PC-1 without this change. The yaml object file was written with help of Claude, and it creates a backtrace like this: ``` frame #0: 0x000000000000000d inner(x=<unavailable>) at inl.cpp:2:13 [inlined] frame #1: 0x000000000000000d outer(x=<unavailable>) at inl.cpp:6:27 ```
googlewalt
pushed a commit
that referenced
this pull request
Sep 10, 2026
To match VirtualSize, and Microsoft's dumpbin which prints both as hex: SECTION HEADER #1 .text name 440B4 virtual size 1000 virtual address (0000000140001000 to 00000001400450B3) 44200 size of raw data llvm-readobj before this change: VirtualSize: 0x3478 VirtualAddress: 0x74000 RawDataSize: 3584 And after: VirtualSize: 0x3478 VirtualAddress: 0x74000 RawDataSize: 0xe00 This was pointed out on llvm#220618, where I was having to manually convert the numbers to compare them.
googlewalt
pushed a commit
that referenced
this pull request
Sep 10, 2026
…m#205764 (llvm#221843) New LifetimeSafetyOpts fields were added in llvm#221610 but they are not initialized in clang/unittests/Analysis/LifetimeSafetyTest.cpp, leading to use-of-uninitialized-memory (https://lab.llvm.org/buildbot/#/builders/164/builds/25165): ``` WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x555571559cbc in clang::lifetimes::internal::(anonymous namespace)::LifetimeChecker::LifetimeChecker(clang::lifetimes::internal::LoanPropagationAnalysis const&, clang::lifetimes::internal::MovedLoansAnalysis const&, clang::lifetimes::internal::LiveOriginsAnalysis const&, clang::lifetimes::internal::FactManager&, clang::AnalysisDeclContext&, clang::lifetimes::LifetimeSafetySemaHelper*, clang::lifetimes::LifetimeSafetyOpts const&) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Analysis/LifetimeSafety/Checker.cpp:108:9 #1 0x5555715453cd in clang::lifetimes::internal::runLifetimeChecker(clang::lifetimes::internal::LoanPropagationAnalysis const&, clang::lifetimes::internal::MovedLoansAnalysis const&, clang::lifetimes::internal::LiveOriginsAnalysis const&, clang::lifetimes::internal::FactManager&, clang::AnalysisDeclContext&, clang::lifetimes::LifetimeSafetySemaHelper*, clang::lifetimes::LifetimeSafetyOpts const&) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Analysis/LifetimeSafety/Checker.cpp:575:19 llvm#2 0x555571524c1e in clang::lifetimes::internal::LifetimeSafetyAnalysis::run() /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Analysis/LifetimeSafety/LifetimeSafety.cpp:98:3 llvm#3 0x55555c3da25b in LifetimeTestRunner /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/unittests/Analysis/LifetimeSafetyTest.cpp:71:15 ... Uninitialized value was stored to memory at #0 0x55555bcd06c7 in __msan_memcpy /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1760:3 #1 0x5555715238ed in clang::lifetimes::internal::LifetimeSafetyAnalysis::LifetimeSafetyAnalysis(clang::AnalysisDeclContext&, clang::lifetimes::LifetimeSafetySemaHelper*, clang::lifetimes::LifetimeSafetyOpts const&) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Analysis/LifetimeSafety/LifetimeSafety.cpp:54:39 llvm#2 0x55555c3da1b9 in make_unique<clang::lifetimes::internal::LifetimeSafetyAnalysis, clang::AnalysisDeclContext &, std::nullptr_t, clang::lifetimes::LifetimeSafetyOpts &, 0> /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/libcxx_install_msan_track_origins/include/c++/v1/__memory/unique_ptr.h:713:30 llvm#3 0x55555c3da1b9 in LifetimeTestRunner /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/unittests/Analysis/LifetimeSafetyTest.cpp:70:9 ``` This patch fixes the issue by initializing the fields in the test to true, which maintains the behavior prior to the new fields being added. Additionally, this patch does a similar drive-by fix to the SuggestAnnotations field (added in llvm#205764). Although there has been no MSan report, that's likely either an MSan false negative or insufficient test coverage.
googlewalt
pushed a commit
that referenced
this pull request
Sep 10, 2026
`target create` never returns for a little-endian 32-bit MIPS ELF file, on any host whose platform advertises `armv7m`/`armv7em` compatibility. On Darwin that is every platform, since `PlatformDarwin::GetCompatibleArchs()` lists both for every arm64/arm64e host and falls through to that same list for any other host core. It is found by `lldb-target-fuzzer`. Reproduce with a 52-byte ELF32 header (`ELFCLASS32`, `ELFDATA2LSB`, `e_machine = EM_MIPS`, `e_flags = EF_MIPS_ARCH_32`, everything else zero), saved as `mips32el.elf`: ``` (lldb) target create mips32el.elf ``` This never returns. Attaching a debugger to the hung process shows the same three frames looping forever, with the call stack never growing: ``` frame #1: cores_match(core1=eCore_arm_armv7m, core2=eCore_mips32el, try_inverse=false, ...) at ArchSpec.cpp:1575 [inlined] frame llvm#2: ArchSpec::IsMatch(rhs=..., match=CompatibleMatch) at ArchSpec.cpp:1449 frame llvm#3: Platform::IsCompatibleArchitecture(...) at Platform.cpp:1193 ``` `cores_match()` checks `core1` against `core2`. When nothing matches and the caller did not ask for an exact match, it sets `try_inverse` and retries once with the two cores swapped. It retries because the rule tables are not symmetric: a core lists only what it accepts, not everything that accepts it. Every case that reaches this fallback must leave `try_inverse` false on the way out, so the swap happens at most once. Three cases, `eCore_arm_armv7em`, `eCore_arm_armv7m`, and `eCore_mips32el`, instead set it back to true unconditionally. When both sides of a comparison are one of these three, the swapped call re-arms `try_inverse`, and the tail call back into `cores_match()` recurses forever. This is a tail call, so an optimizing compiler turns the recursion into a loop instead of a growing stack. That is why the process spins instead of crashing with a stack overflow. The three cases cannot simply leave `try_inverse` false like their siblings. `ArchSpec("mipsel").IsCompatibleMatch(ArchSpec("mips64el"))` is true today only because of this same swap: `eCore_mips32el`'s own rule says nothing about 64-bit MIPS, but `eCore_mips64el`'s rule accepts any 32-bit MIPS core with the same endianness, and only the inverted comparison reaches that rule. Instead, split the switch into a one-directional helper that never recurses, and try both directions from a plain, non-recursive wrapper: ``` cores_match(A, B) := cores_match_one_direction(A, B) || cores_match_one_direction(B, A) ``` This keeps every existing one-directional rule exactly as it was, including the mips32el/mips64el rule above, and makes a second retry impossible no matter what any case does. Adds two regression tests to ArchSpecTest.cpp. One asserts that the previously-hanging pairs now return false right away. The other locks in the two relationships that depend on checking both directions, so a future change cannot bring the recursion back by "fixing" the three cases the naive way. Assisted-by: claude
googlewalt
pushed a commit
that referenced
this pull request
Sep 10, 2026
) BufferedStackTrace::UnwindFast walks the stack assuming frame[0] is the caller's frame pointer and frame[1] the return address. Alpha chains neither, so the walk yields a few garbage frames and then stops: ``` freed by thread T0 here: #0 0x020000971274 in free asan_malloc_linux.cpp:51 #1 0x0200007fa48c (<unknown module>) ``` Opt Alpha out of the fast unwinder the way Linux/MIPS already is. The _Unwind_Backtrace based unwinder gives complete traces; with it, GCC's g++.dg/asan/deep-stack-uaf-1.C passes on alpha-unknown-linux-gnu.
googlewalt
pushed a commit
that referenced
this pull request
Sep 24, 2026
…#225472) The ASan bots hit a use-after-free unwinding the scripted process in TestScriptedProcess: ``` READ of size 512 #1 DataExtractor::CopyByteOrderedData() DataExtractor.cpp:660 llvm#2 ScriptedProcess::DoReadMemory() ScriptedProcess.cpp:282 llvm#3 Process::ReadMemoryFromInferior() Process.cpp:2453 llvm#4 MemoryCache::Read() Memory.cpp:323 ``` AddressableBitsScriptedProcess.read_memory_at_address(), added in 851eb5a, filled its SBData with SetData(). That overload is non-owning: it builds a DataExtractor that aliases the caller's buffer. The buffer it was handed is a `bytes(size)` temporary, which Python frees as soon as the call returns, so DoReadMemory copies out of a dead allocation. The 512 is the default target.memory-cache-line-size, not the register width the unwinder asked for. Use SetDataWithOwnership() instead, as every other scripted process script already does. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
googlewalt
pushed a commit
that referenced
this pull request
Sep 24, 2026
…lvm#224001) Running the `HighlighterTests` unit test under AddressSanitizer aborts on every Swift test case, for example `SwiftComments`: ``` ==69424==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000008070 at pc 0x000116a1f36c bp 0x00016d07c3c0 sp 0x00016d07c3b8 READ of size 4 at 0x602000008070 thread T0 #0 0x000116a1f368 in eat_raw_str_part scanner.c:700 #1 0x000116a1b5f4 in tree_sitter_swift_external_scanner_scan scanner.c:858 llvm#2 0x00012cc77420 in ts_parser_parse llvm#3 0x00012cc79afc in ts_parser_parse_string llvm#4 0x00010a3536a4 in lldb_private::TreeSitterHighlighter::Highlight(...) 0x602000008071 is located 0 bytes after 1-byte region [0x602000008070,0x602000008071) allocated by thread T0 here: #0 0x00012d68d560 in calloc #1 0x00012cc763b8 in ts_parser_parse llvm#2 0x00012cc79afc in ts_parser_parse_string ``` `eat_raw_str_part` reads `state->ongoing_raw_str_hash_count` as its first statement, a 4 byte field, but the scanner state was allocated with: ``` void *tree_sitter_swift_external_scanner_create() { return calloc(0, sizeof(struct ScannerState)); } ``` `calloc` with an element count of 0 has no obligation to reserve room for `sizeof(struct ScannerState)`, so it works by accident, but is found by ASAN. Fix it by allocating one instance, matching the Rust scanner and the struct's actual use as a single persistent state object across calls. The existing `HighlighterTest.Swift*` tests already exercise this path end to end and catch the regression under AddressSanitizer; no new test is needed.
googlewalt
pushed a commit
that referenced
this pull request
Sep 29, 2026
…226936) Fixes llvm#191859. On Arm one of the functions has no name, which is a valid state. ``` Num frames: 7 0 frame #0: 0x092a151c a.out`baz at main.c:5:3 --name: baz 1 frame #1: 0x092a1540 a.out`bar at main.c:10:10 --name: bar 2 frame llvm#2: 0x092a1560 a.out`foo at main.c:15:10 --name: foo 3 frame llvm#3: 0x092a158c a.out`main at main.c:20:10 --name: main 4 frame llvm#4: 0xf7ab939a libc.so.6` --name: None 5 frame llvm#5: 0xf7ab943e libc.so.6`__libc_start_main + 94 --name: __libc_start_main 6 frame llvm#6: 0x092a1434 a.out`_start + 40 --name: _start ``` The prefix provider needs to handle that possibility. Though the Python type annotations on ScriptedFrame say that the name methods return string, in reality they can return None, which the C++ sides expect. I will fix that in another PR.
googlewalt
pushed a commit
that referenced
this pull request
Sep 29, 2026
This test has been failing on AArch64 Linux recently. Either with SIGSEGV or SIGABRT (less often that one). I could reproduce it locally by varying system load, and got this out of a core file: ``` * thread #1, name = 'test_python_sto', stop reason = SIGSEGV: address not mapped to object (fault address=0xc17d18317552db80) * frame #0: 0x0000ef7dc72ac6cc libc.so.6`__GI_memchr at memchr.S:68 frame #1: 0x0000ef7dc727cf4c libc.so.6`_IO_getline_info(fp=0x0000b9b53a8bd180, buf="\xa9\xb4\t\xce}\xef", n=<unavailable> , delim=10, extract_delim=1, eof=0x0000000000000000) at iogetline.c:85:17 frame llvm#2: 0x0000ef7dc727bdc4 libc.so.6`_IO_fgets(buf="\xa9\xb4\t\xce}\xef", n=<unavailable>, fp=0x0000b9b53a8bd180) at io fgets.c:53:11 frame llvm#3: 0x0000ef7dc80f2b80 liblldb.so.24.0git`lldb_private::IOHandlerEditline::GetLine(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>&, bool&) + 996 frame llvm#4: 0x0000ef7dc80f41f4 liblldb.so.24.0git`lldb_private::IOHandlerEditline::Run() + 180 frame llvm#5: 0x0000ef7dc80bf614 liblldb.so.24.0git`lldb_private::Debugger::RunIOHandlers() + 128 frame llvm#6: 0x0000ef7dc80ccee8 liblldb.so.24.0git`std::_Function_handler<void* (), lldb_private::Debugger::StartIOHandlerTh read()::$_0>::_M_invoke(std::_Any_data const&) + 28 frame llvm#7: 0x0000ef7dc81e1608 liblldb.so.24.0git`lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) + 124 frame llvm#8: 0x0000ef7dc72903c8 libc.so.6`start_thread(arg=0x000000000080e640) at pthread_create.c:442:8 frame llvm#9: 0x0000ef7dc72f9fdc libc.so.6`thread_start at clone.S:79 ``` What's happening is that the interpreter's input stream is set to stream A, then we reset it to the default, then close stream A. There may still be reads from stream A in flight when we close it, which lead to the crash. The solution is to wait on the interpreter thread to finish whatever it's doing. SBDebuger::Destroy does that. Normally that would be called by driver.cpp but it can be called on already destroyed objects. So for this test we'll call it twice, but that's not a problem.
googlewalt
pushed a commit
that referenced
this pull request
Oct 26, 2026
…biner (llvm#234727) The legalizer can create chains of shifts by constants that the pre-legalizer combiner never sees. Adding `shift_immed_chain` to the post-legalizer combiner merges them. ```llvm define i16 @test(i16 %a) { %r = sdiv i16 %a, 7 ret i16 %r } ``` Before (7 instructions): ``` sxth w8, w0 mov w9, llvm#18725 mul w8, w8, w9 asr w8, w8, llvm#16 asr w8, w8, #1 ubfx w9, w8, llvm#15, #1 add w0, w8, w9 ``` After (6 instructions): ``` sxth w8, w0 mov w9, llvm#18725 mul w8, w8, w9 asr w8, w8, llvm#17 ubfx w9, w8, llvm#15, #1 add w0, w8, w9 ``` The rule rewrites the existing shift in place with a new constant amount of the same type, so it does not create illegal instructions. The same applies to other i8/i16 division and remainder by a constant in combine-sdiv.ll and rem-by-const.ll.
googlewalt
pushed a commit
that referenced
this pull request
Oct 26, 2026
## Summary Optimize Thumb-2 code generation for zero tests of values masked by contiguous low-bit masks. For these tests, shifting the input can preserve whether the masked value is zero while avoiding a `BIC`. The four source forms covered by this pattern reduce to one of two zero-test shapes: an `i32` test or an `i64` test lowered across two `i32` halves. ## Changes - Add a helper to recognize eligible single-use ANDs with contiguous low masks and form an equivalent shifted value for a zero test. - Apply the transform to Thumb-2 equality and inequality comparisons against zero, including the OR of halves produced when an `i64` comparison is lowered. - Preserve existing lowering for byte and halfword masks (`UXTB`/`UXTH`), as well as for masks and comparisons where shifting does not preserve the relevant result. - Add regression coverage for optimized `i32` and `i64` cases and for cases where the transform must not apply, including noncontiguous masks, signed comparisons, nonzero comparisons, and multiple uses. ## Related Issues and Extra Comments Resolves llvm#224748 Thumb-2 may fold the shifted operand into the OR, producing the equivalent `orr.w r0, r0, r1, lsl #1`. `CLZ` and `LSRS llvm#5` remain because they convert the zero test into an `i1`: `CLZ` returns 32 for zero and at most 31 for nonzero, so shifting right by five yields 1 for zero and 0 otherwise. The transform deliberately skips `0xff` and `0xffff` masks. Thumb-2 already lowers those efficiently with `UXTB` and `UXTH`, so shifting is unnecessary for those cases. ## Testing `llvm/test/CodeGen/ARM/icmp-mask-zero.ll`
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
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.