Repository navigation
Conversation
trdthg
force-pushed
the
buddy-mlir-backend
branch
2 times, most recently
from
April 20, 2026 12:27
cae61e8 to
5faa117
Compare
yuzibo
force-pushed
the
main
branch
5 times, most recently
from
May 9, 2026 07:48
4ab1448 to
4851970
Compare
WuXintong123
force-pushed
the
main
branch
7 times, most recently
from
May 14, 2026 14:17
9f45e3c to
1e7ae41
Compare
WuXintong123
pushed a commit
that referenced
this pull request
May 14, 2026
llvm#183506 revealed a pre-existing use-after-scope in createInstrInfo (MSan bot: https://lab.llvm.org/buildbot/#/builders/164/builds/21562 [*]). This patch fixes the issue by changing the stack-allocated AArch64Subtarget (which goes out of scope once createInstrInfo() returns) into heap-allocated, allowing it to be safely stored in the returned AArch64InstrInfo. ----- [*] WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x55555666fabd in llvm::AArch64InstrInfo::getInstSizeInBytes(llvm::MachineInstr const&) const /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp:247:5 ... /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/unittests/Target/AArch64/InstSizes.cpp:85:3 #9 0x555556508559 in InstSizes_MOVaddrTagged_Test::TestBody() /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/unittests/Target/AArch64/InstSizes.cpp:301:3 ... Member fields were destroyed #0 0x555556498a1d in __sanitizer_dtor_callback_fields /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1074:5 #1 0x5555564fbda6 in ~Triple /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/include/llvm/TargetParser/Triple.h:348:12 #2 0x5555564fbda6 in ~Triple /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/include/llvm/TargetParser/Triple.h:47:7 #3 0x5555564fbda6 in llvm::AArch64Subtarget::~AArch64Subtarget() /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/lib/Target/AArch64/AArch64Subtarget.h:38:7 #4 0x555556503396 in (anonymous namespace)::createInstrInfo(llvm::TargetMachine*) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/unittests/Target/AArch64/InstSizes.cpp:38:1 #5 0x5555565084cb in InstSizes_MOVaddrTagged_Test::TestBody() /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/unittests/Target/AArch64/InstSizes.cpp:299:42
WuXintong123
force-pushed
the
main
branch
8 times, most recently
from
May 22, 2026 14:05
c50a52c to
98bad71
Compare
WuXintong123
force-pushed
the
main
branch
3 times, most recently
from
May 27, 2026 02:32
1dcaa37 to
1b19ecc
Compare
…opsrun test (llvm#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.
Co-authored-by: Cursor <cursoragent@cursor.com>
trdthg
force-pushed
the
buddy-mlir-backend
branch
from
June 2, 2026 06:54
5faa117 to
35c0800
Compare
trdthg
force-pushed
the
buddy-mlir-backend
branch
from
June 2, 2026 07:28
35c0800 to
63ed51e
Compare
WuXintong123
pushed a commit
that referenced
this pull request
Jun 5, 2026
Fix llvm#201615. Fix the issue that non atomic operations race in waiting queue, which causes missed futex wakeup signals. Confirmed by TSAN: ``` ================== WARNING: ThreadSanitizer: data race (pid=388518) Write of size 4 at 0x7ffd21cf98e4 by thread T23: #0 __llvm_libc_23_0_0_git::RawRwLock::notify_pending_threads() ./libc/src/__support/threads/raw_rwlock.h:443:44 #1 __llvm_libc_23_0_0_git::RawRwLock::unlock() ./libc/src/__support/threads/raw_rwlock.h:520:5 #2 randomized_thread_operation(SharedData*) ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:104:18 #3 thread_runner(void*) ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:148:5 Previous atomic read of size 4 at 0x7ffd21cf98e4 by thread T4: #0 __llvm_libc_23_0_0_git::cpp::Atomic<unsigned int>::load(...) ./libc/src/__support/CPP/atomic.h:115:5 #1 __llvm_libc_23_0_0_git::Futex::wait(...) ./libc/src/__support/threads/linux/futex_utils.h:43:17 #2 __llvm_libc_23_0_0_git::cpp::expected<int, int> __llvm_libc_23_0_0_git::rwlock::WaitingQueue::wait<Role::Reader>(...) ./libc/src/__support/threads/raw_rwlock.h:101:35 #3 __llvm_libc_23_0_0_git::rwlock::LockResult __llvm_libc_23_0_0_git::RawRwLock::lock_slow<Role::Reader>(...) ./libc/src/__support/threads/raw_rwlock.h:402:34 #4 __llvm_libc_23_0_0_git::RawRwLock::read_lock(...) ./libc/src/__support/threads/raw_rwlock.h:485:12 #5 randomized_thread_operation(SharedData*) ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:79:16 #6 thread_runner(void*) ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:148:5 Thread T23 (tid=388553, running) created by main thread at: #0 pthread_create ... #1 main ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:166:5 Thread T4 (tid=388533, running) created by main thread at: #0 pthread_create ... #1 main ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:166:5 SUMMARY: ThreadSanitizer: data race ./libc/src/__support/threads/raw_rwlock.h:443:44 in __llvm_libc_23_0_0_git::RawRwLock::notify_pending_threads() ================== ``` AI wrote the detection script. Manually fixed.
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) #23 0x000062735c358705 lldb_dap::DAP::Loop() (/home/sergei/llvm-project/build/bin/lldb-dap+0x94705) #24 0x000062735c2ed0c7 main (/home/sergei/llvm-project/build/bin/lldb-dap+0x290c7) #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
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 6, 2026
…lvm#207008) `Evaluate_DW_OP_convert` dereferenced `eval_ctx.dwarf_cu` (the `DWARFExpression` Delegate) whenever the operand DIE offset was non-zero, and unconditionally read `eval_ctx.stack.back()`. When a DWARF expression is evaluated without a DWARF unit (as the lldb-dwarf-expression-fuzzer does), two operand shapes crash: - `DW_OP_convert` with a non-zero offset calls `dwarf_cu->GetDIEBitSizeAndSign(...)` on a null Delegate. - `DW_OP_convert` with nothing on the stack reads the back of an empty vector. The unit test feeds both with `dwarf_cu == nullptr` and crashes: ``` [ RUN ] DWARFExpression.DW_OP_convert #2 SignalHandler(int, __siginfo*, void*) #4 DWARFExpression::Evaluate(...) #5 Evaluate(ArrayRef<unsigned char>, ...) ``` (SIGSEGV, the process aborts.) Bail out with an error when the stack is empty, and when a non-zero DIE offset is requested without a DWARF unit, instead of crashing. Extends `DWARFExpression.DW_OP_convert` with these two cases, which crash without the fix. --------- Co-authored-by: Michael Buch <michaelbuch12@gmail.com>
WuXintong123
pushed a commit
that referenced
this pull request
Jul 30, 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) #2 0x0000000105b7b170 SignalHandler(int, __siginfo*, void*) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x102f63170) #3 0x000000018b5f7744 (/usr/lib/system/libsystem_platform.dylib+0x1804fb744) #4 0x000000018b5ed8d8 (/usr/lib/system/libsystem_pthread.dylib+0x1804f18d8) #5 0x000000018b4f4644 (/usr/lib/system/libsystem_c.dylib+0x1803f8644) #6 0x000000018b4f38a0 (/usr/lib/system/libsystem_c.dylib+0x1803f78a0) #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) #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) #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) #10 0x00000001058d90b4 llvm::TargetTransformInfo::getInstructionCost(llvm::User const*, llvm::TargetTransformInfo::TargetCostKind) const (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x102cc10b4) #11 0x000000010468a368 getCost(llvm::Instruction&, llvm::TargetTransformInfo::TargetCostKind, llvm::TargetTransformInfo&) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x101a72368) #12 0x0000000104689dd4 llvm::CostModelPrinterPass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x101a71dd4) #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) #14 0x000000010518a680 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x102572680) #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) #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) #17 0x0000000106131eac optMain (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x103519eac) #18 0x000000018b22fe00 zsh: abort build-assert/bin/opt -mtriple=wasm32-unknown-unknown -mattr=+simd128 ```
WuXintong123
pushed a commit
that referenced
this pull request
Aug 18, 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)
#2 0x0000000103c69130 SignalHandler(int, __siginfo*, void*) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1030e9130)
#3 0x000000018b5f7744 (/usr/lib/system/libsystem_platform.dylib+0x1804fb744)
#4 0x000000018b5ed8d8 (/usr/lib/system/libsystem_pthread.dylib+0x1804f18d8)
#5 0x000000018b4f4644 (/usr/lib/system/libsystem_c.dylib+0x1803f8644)
#6 0x0000000103bbc0b4 llvm::report_fatal_error(llvm::Twine const&, bool) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x10303c0b4)
#7 0x0000000103af91b8 llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f791b8)
#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)
#9 0x0000000101f66b78 (anonymous namespace)::WebAssemblyDAGToDAGISel::Select(llvm::SDNode*) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1013e6b78)
#10 0x0000000103aee46c llvm::SelectionDAGISel::DoInstructionSelection() (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f6e46c)
#11 0x0000000103aed400 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f6d400)
#12 0x0000000103aeb4b4 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f6b4b4)
#13 0x0000000103ae8ba8 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f68ba8)
#14 0x0000000103ae6cd8 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f66cd8)
#15 0x0000000102b71d28 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x101ff1d28)
#16 0x0000000103096900 llvm::FPPassManager::runOnFunction(llvm::Function&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102516900)
#17 0x000000010309cc00 llvm::FPPassManager::runOnModule(llvm::Module&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x10251cc00)
#18 0x0000000103097174 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102517174)
#19 0x0000000100b880a4 main (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1000080a4)
#20 0x000000018b22fe00
zsh: abort build-assert/bin/llc -mtriple=wasm32-unknown-unknown -mattr=+simd128,+fp16 -o
```
WuXintong123
pushed a commit
that referenced
this pull request
Sep 1, 2026
Make distributedBarrier::stillNeed atomic and use release/acquire
ordering for distributed barrier gather arrival flags.
The old volatile stillNeed flag did not synchronize an arriving thread's
pre-barrier writes with the thread that observed its arrival. On weakly
ordered architectures, a group leader could observe stillNeed == 0
before the arriving thread's pre-barrier writes were visible. This
allowed another thread to pass the barrier and read stale data written
before the barrier.
Use release stores when publishing stillNeed == 0. Keep the spin loops
on relaxed loads, then perform one acquire fence after all expected zero
values have been observed. This connects the arriving threads'
pre-barrier writes to the observer through the standard release/acquire
happens-before chain, without using acquire loads on every poll.
The same pattern is used when a group leader publishes its own stillNeed
== 0 after the in-group gather completes. The existing go-flag
release/acquire path then carries the ordering to threads leaving the
barrier.
Initialization and next-iteration reset stores remain relaxed because
they do not publish pre-barrier data.
On x86, this does not change the generated instruction sequence for the
affected stillNeed polling/arrival code, since TSO already provides the
needed ordering for ordinary loads and stores.
Reproducer:
I used the following stress test to reproduce the distributed-barrier
visibility issue on AArch64 (Grace).
`test.c`:
```c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <omp.h>
int main() {
int nt;
#pragma omp parallel
#pragma omp master
nt = omp_get_num_threads();
int n = 1024;
int *p = aligned_alloc(64, nt * n * sizeof(int));
memset(p, 0, nt * n * sizeof(int));
#pragma omp parallel
{
int t = omp_get_thread_num();
int *pt = p + t * n;
int *pt2 = p + ((t + 1) % nt) * n;
for (int it = 1; it <= 100000; it++) {
for (int i = 0; i < n; i++)
pt[i] = it;
#pragma omp barrier
for (int i = 0; i < n; i++) {
if (pt2[i] != it) {
printf("thread #%d observes pt2[%d] != %d\n", t, i, it);
abort();
}
}
#pragma omp barrier
}
}
printf("ok\n");
return 0;
}
```
`noise.c`:
```c
// background memory-bandwidth noise
#include <stdlib.h>
#include <omp.h>
int main() {
long N = 1024L*1024;
#pragma omp parallel
{
long *b = malloc(sizeof(long)*N);
for (long j=0; j<1000; j++)
for (long i = 0; i < N; i += 8)
b[i] += 1;
}
return 0;
}
```
Build and run:
```bash
clang test.c -O -fopenmp -o test
clang noise.c -O -fopenmp -o noise
./noise &
KMP_PLAIN_BARRIER_PATTERN=dist,dist \
KMP_FORKJOIN_BARRIER_PATTERN=dist,dist \
KMP_REDUCTION_BARRIER_PATTERN=dist,dist \
OMP_NUM_THREADS=10 \
./test
```
With the old runtime, this can fail as follows:
```text
thread #5 observes pt2[112] != 343
Aborted (core dumped)
```
The same test passes with the patched runtime.
WuXintong123
pushed a commit
that referenced
this pull request
Sep 2, 2026
When flang is built with ASAN, one of the unit tests fails:
```
[ RUN ] FrontendActionTest.ParseSyntaxOnly
=================================================================
==94036==ERROR: AddressSanitizer: heap-use-after-free on address 0xef60299e1268 at pc 0xbf00842915d0 bp 0xffffcc819e50 sp 0xffffcc819e48
READ of size 2 at 0xef60299e1268 thread T0
#0 0xbf00842915cc in getShowColors /home/davspi01/llvm-project/llvm/../clang/include/clang/Basic/DiagnosticOptions.def:68:14
#1 0xbf00842915cc in showColors /home/davspi01/llvm-project/llvm/../clang/include/clang/Basic/DiagnosticOptions.h:159:13
#2 0xbf00842915cc in Fortran::frontend::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level, clang::Diagnostic const&) /home/davspi01/llvm-project/flang/lib/Frontend/TextDiagnosticPrinter.cpp:116:27
#3 0xbf0088f08ef0 in clang::DiagnosticsEngine::Report(clang::DiagnosticsEngine::Level, clang::Diagnostic const&) /home/davspi01/llvm-project/clang/lib/Basic/Diagnostic.cpp:625:11
#4 0xbf0088f09584 in clang::DiagnosticsEngine::ProcessDiag(clang::DiagnosticBuilder const&) /home/davspi01/llvm-project/clang/lib/Basic/Diagnostic.cpp:705:3
#5 0xbf0088f099ac in clang::DiagnosticsEngine::EmitDiagnostic(clang::DiagnosticBuilder const&, bool) /home/davspi01/llvm-project/clang/lib/Basic/Diagnostic.cpp:727:15
#6 0xbf0082d78778 in Emit /home/davspi01/llvm-project/llvm/../clang/include/clang/Basic/Diagnostic.h:1332:28
#7 0xbf0082d78778 in clang::DiagnosticBuilder::~DiagnosticBuilder() /home/davspi01/llvm-project/llvm/../clang/include/clang/Basic/Diagnostic.h:1367:26
#8 0xbf0083dacd7c in Fortran::frontend::FrontendAction::reportFatalSemanticErrors() /home/davspi01/llvm-project/flang/lib/Frontend/FrontendAction.cpp:310:5
<...>
```
* CompilerInstance is defaut constructed, which means it has a default
constructed CompilerInvocation.
* CompilerInstance::createDiagnostics is called.
* It makes a clang::DiagnosticsEngine and gives it a reference to
whatever getDiagnosticOpts() returns.
* That returns invocation->getDiagnosticOpts().
* CompilerInstance::setInvocation is called with a new invocation,
replacing the original invocation.
* The clang::DiagnosticsEngine now has a dangling reference to the
options in the original invocation.
To fix this, I have implemented the same thing that
b69dcb8 did for Clang.
Pass the invocation to the CompilerInstance constructor, and remove the
setInvocation method. So that you cannot mix up the order.
WuXintong123
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 #2: 0x092a1560 a.out`foo at main.c:15:10 --name: foo 3 frame #3: 0x092a158c a.out`main at main.c:20:10 --name: main 4 frame #4: 0xf7ab939a libc.so.6` --name: None 5 frame #5: 0xf7ab943e libc.so.6`__libc_start_main + 94 --name: __libc_start_main 6 frame #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.
WuXintong123
pushed a commit
that referenced
this pull request
Sep 30, 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 #2: 0x0000ef7dc727bdc4 libc.so.6`_IO_fgets(buf="\xa9\xb4\t\xce}\xef", n=<unavailable>, fp=0x0000b9b53a8bd180) at io fgets.c:53:11 frame #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 #4: 0x0000ef7dc80f41f4 liblldb.so.24.0git`lldb_private::IOHandlerEditline::Run() + 180 frame #5: 0x0000ef7dc80bf614 liblldb.so.24.0git`lldb_private::Debugger::RunIOHandlers() + 128 frame #6: 0x0000ef7dc80ccee8 liblldb.so.24.0git`std::_Function_handler<void* (), lldb_private::Debugger::StartIOHandlerTh read()::$_0>::_M_invoke(std::_Any_data const&) + 28 frame #7: 0x0000ef7dc81e1608 liblldb.so.24.0git`lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) + 124 frame #8: 0x0000ef7dc72903c8 libc.so.6`start_thread(arg=0x000000000080e640) at pthread_create.c:442:8 frame #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.
WuXintong123
pushed a commit
that referenced
this pull request
Oct 7, 2026
## Description When I enable GlobalISel for SystemZ by adding `tablegen(LLVM SystemZGenGlobalISel.inc -gen-global-isel)` in `SystemZ/CMakeList`, it crashes with this trace: ``` 0. Program arguments: /Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen -gen-global-isel -I/Users/dennis/Developer/llvm-project/llvm/lib/Target/SystemZ -I/Users/dennis/Developer/llvm-project/build/include -I/Users/dennis/Developer/llvm-project/llvm/include -I /Users/dennis/Developer/llvm-project/llvm/lib/Target /Users/dennis/Developer/llvm-project/llvm/lib/Target/SystemZ/SystemZ.td --write-if-changed -o SystemZGenGlobalISel.inc -d SystemZGenGlobalISel.inc.d #0 0x00000001004897ac llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x1002f17ac) #1 0x0000000100486ff0 llvm::sys::RunSignalHandlers() (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x1002eeff0) #2 0x000000010048a0cc SignalHandler(int, __siginfo*, void*) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x1002f20cc) #3 0x0000000184d8c144 (/usr/lib/system/libsystem_platform.dylib+0x180898144) #4 0x00000001003a1158 llvm::gi::CopyConstantAsImmRenderer& llvm::gi::BuildMIAction::addRenderer<llvm::gi::CopyConstantAsImmRenderer, llvm::gi::RuleMatcher&, llvm::StringRef&>(llvm::gi::RuleMatcher&, llvm::StringRef&) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x100209158) #5 0x00000001003a1158 llvm::gi::CopyConstantAsImmRenderer& llvm::gi::BuildMIAction::addRenderer<llvm::gi::CopyConstantAsImmRenderer, llvm::gi::RuleMatcher&, llvm::StringRef&>(llvm::gi::RuleMatcher&, llvm::StringRef&) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x100209158) #6 0x00000001003a0688 (anonymous namespace)::GlobalISelEmitter::importNodeRenderer(llvm::gi::RuleMatcher&, llvm::gi::BuildMIAction&, llvm::TreePatternNode const&, std::__1::__list_iterator<std::__1::unique_ptr<llvm::gi::MatchAction, std::__1::default_delete<llvm::gi::MatchAction>>, void*>&) const (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x100208688) #7 0x000000010039f11c (anonymous namespace)::GlobalISelEmitter::importExplicitUseRenderers(std::__1::__list_iterator<std::__1::unique_ptr<llvm::gi::MatchAction, std::__1::default_delete<llvm::gi::MatchAction>>, void*>, llvm::gi::RuleMatcher&, llvm::gi::BuildMIAction&, llvm::TreePatternNode const&) const (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x10020711c) #8 0x0000000100394a6c (anonymous namespace)::GlobalISelEmitter::run(llvm::raw_ostream&) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x1001fca6c) #9 0x0000000100392f74 llvm::TableGen::Emitter::OptClass<(anonymous namespace)::GlobalISelEmitter>::run(llvm::StringRef, llvm::RecordKeeper const&) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x1001faf74) #10 0x00000001004aea9c llvm::TableGen::Emitter::ApplyCallback(llvm::RecordKeeper const&, llvm::TableGenOutputFiles&, llvm::StringRef) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x100316a9c) #11 0x000000010048e968 llvm::TableGenMain(char const*, llvm::function_ref<bool (llvm::TableGenOutputFiles&, llvm::RecordKeeper const&)>) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x1002f6968) #12 0x00000001001f76d4 tblgen_main(int, char**) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x10005f6d4) #13 0x00000001849abe80 /bin/sh: line 1: 45648 Segmentation fault: 11 /Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen -gen-global-isel -I/Users/dennis/Developer/llvm-project/llvm/lib/Target/SystemZ -I/Users/dennis/Developer/llvm-project/build/include -I/Users/dennis/Developer/llvm-project/llvm/include -I /Users/dennis/Developer/llvm-project/llvm/lib/Target /Users/dennis/Developer/llvm-project/llvm/lib/Target/SystemZ/SystemZ.td --write-if-changed -o SystemZGenGlobalISel.inc -d SystemZGenGlobalISel.inc.d ninja: build stopped: subcommand failed. ``` Note that it compiles with no issues when it doesn't have the GlobalISel instruction on the CMakeList setting. Turns out the pattern is using `imm` when it should be an `timm`, causing the pattern to break. After applying my changes, I was able to build the SystemZ compiler and also ran the entire LLVM test suite. ### AI usage - AI was used to help me decipher the stack trace and find out which pattern was causing the issue. - AI was used to help explain the difference between `imm` and `timm`, amongst other keywords. - AI was used to tell me what commands to run to build, and test if my changes worked.
Yranger
pushed a commit
to Yranger/llvm-project
that referenced
this pull request
Oct 13, 2026
…m#220167) In libgcc, these conversion routines use integers in the signature. In practice compiler-rt's definition has worked because the AAPCS calling convention passes and returns floats the same as the same-sized integer, but this may not be the case on all platforms. Thus, update the signatures to match GCC. This new version calls the inlined functions directly., changing the generated code from: 00000000 <__extendhfsf2>: 0: ee100a10 vmov r0, s0 4: e1a01000 mov r1, r0 <snip> 60: e1800001 orr r0, r0, r1 64: ee000a10 vmov s0, r0 68: e12fff1e bx lr 0000006c <__gnu_h2f_ieee>: 6c: e92d4800 push {fp, lr} 70: ee000a10 vmov s0, r0 74: ebfffffe bl 0 <__extendhfsf2> 78: ee100a10 vmov r0, s0 7c: e8bd8800 pop {fp, pc} To: 00000000 <__extendhfsf2>: 0: ee100a10 vmov r0, s0 4: e1a01000 mov r1, r0 <snip> 60: e1800001 orr r0, r0, r1 64: ee000a10 vmov s0, r0 68: e12fff1e bx lr 0000006c <__gnu_h2f_ieee>: 6c: e1a01000 mov r1, r0 70: e7e42550 ubfx r2, r0, RuyiAI-Stack#10, RuyiAI-Stack#5 <snip> c8: e1800001 orr r0, r0, r1 cc: e12fff1e bx lr This avoids an unnecessary indirection and register shuffle when calling `__gnu_h2f_ieee`. It does mean the code is effectively duplicated however, since any given target will only ever use `__gnu_h2f_ieee` or `__extendhfsf2` but never mix them, this is an improvement in the final binary. (The same logic applies to `__gnu_f2h_ieee` and `__truncsfhf2`.)
WuXintong123
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 #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.