[AArch64] Tweak fixed-length loop.dependence.mask costs (#175538)
For fixed-length masks we need to AND the result of the whilewr/rw with
`ptrue vl*` (which is at least one more instruction).
[flang][NFC] Extract ArraySectionAnalyzer from OptimizedBufferization (#180278)
Extract `ArraySectionAnalyzer` from `OptimizedBufferization` into a
standalone
analysis utility so it can be reused by other passes (e.g.,
`ScheduleOrderedAssignments`).
Also extracts the logic to detect if a designate is using the indices
of an elemental operation in storage order.
This will be used in WHERE construct optimization in the next patch.
workflows/release-asset-audit: Split workflow into two jobs (#179833)
This way we can assign an environment to the job that uses the
ISSUE_SUBSCRIBER_TOKEN secret.
(cherry picked from commit 549172139cf547c3fcaa5d52bd70a55ffc0db286)
[ubsan][test] Skip Misc/Posix/static-link.cpp on Solaris (#175464)
The `UBSan-Standalone-x86_64 :: TestCases/Misc/Posix/static-link.cpp`
test currently `FAIL`s on Solaris/x86_64 with
```
ld: fatal: option '-z record' is incompatible with building a static executable
```
One cannot create static executables on Solaris since no `libc.a` is
delivered, so this patch skips the test.
Tested on `x86_64-pc-solaris2.11`.
(cherry picked from commit 5c2b510f882129fcdb3945842e3d050b068f3cda)
[lldb-dap] Remove end line and column from disassemble response (#180037)
The end line entry calculated from the instruction's end address is
unreliable and could produce incorrect source ranges. especially if the
instruction spans multiple lines.
We can end in situations where the current end line is the next start
line and the source line is show to the client twice. confusing users
what maps to what.
| With EndLine |
| :------------: |
| <img width="892" height="486" alt="Screenshot 2026-02-05 at 21 37 08"
src="https://github.com/user-attachments/assets/f2fef592-5754-4168-bf93-2baba4742c5d"
/> |
| Without Endline |
| :---------------: |
| <img width="892" height="486" alt="Screenshot 2026-02-05 at 21 59 29"
[20 lines not shown]
[lldb] Add support for ScriptedFrame to provide values/variables. (#178575)
This patch adds plumbing to support the implementations of StackFrame::Get{*}Variable{*} on ScriptedFrame. The major pieces required are:
- A modification to ScriptedFrameInterface, so that we can actually call the python methods.
- A corresponding update to the python implementation to call the python methods.
- An implementation in ScriptedFrame that can get the variable list on construction inside ScriptedFrame::Create, and pass that list into the ScriptedFrame so it can get those values on request.
There is a major caveat, which is that if the values from the python side don't have variables attached, right now, they won't be passed into the scripted frame to be stored in the variable list. Future discussions around adding support for 'extended variables' when printing frame variables may create a reason to change the VariableListSP into a ValueObjectListSP, and generate the VariableListSP on the fly, but that should be addressed at a later time.
This patch also adds tests to the frame provider test suite to prove these changes all plumb together correctly.
Related radar: rdar://165708771
(cherry picked from commit 10f2611c2173783efae8aebc32d1515013271b64)
[lldb] Fix variable access in old SBFrames after inferior function calls (#178823)
When a user holds an SBFrame reference and then triggers an inferior
function
call (via expression evaluation or GetExtendedBacktraceThread),
variables in
that frame become inaccessible with "register fp is not available"
errors.
This happens because inferior function calls execute through
ThreadPlanCallFunction, which calls ClearStackFrames() during cleanup to
invalidate the unwinder state. ExecutionContextRef objects in the old
SBFrames
were tracking StackFrameLists via weak_ptr, which became stale when
ClearStackFrames() created new instances.
The fix uses stable StackFrameList identifiers that persist across
ClearStackFrames():
- ID = 0: Normal unwinder frames (constant across all instances)
[37 lines not shown]
[lldb] Broadcast `eBroadcastBitStackChanged` when frame providers change (#171482)
We want to reload the call stack whenever the frame providers are
updated. To do so, we now emit a `eBroadcastBitStackChanged` on all
threads whenever any changes to the frame providers take place.
I found this very useful while iterating on a frame provider in
lldb-dap. So far, the new frame provider only took effect after
continuing execution. Now the backtrace in VS-Code gets refreshed
immediately upon running `target frame-provider add`.
(cherry picked from commit 943782be5aec5db854065145dd73a618c3a775be)
[lldb] Move ValueImpl and ValueLocker to ValueObject, NFC. (#178573)
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.
(cherry picked from commit 58f623c504d14743e465f988848f9c16dc220a3b)
[lldb] Fix test_chained_frame_providers on 32-bit Arm (#177668)
PC addresses must always be 16-bit aligned on 32-bit Arm CPUs.
Fixes #177666
(cherry picked from commit cd70e2d8367493785f1591045db2151540b14b91)
[lldb] Enable chaining multiple scripted frame providers per thread (#172849)
This patch allows threads to have multiple SyntheticFrameProviderSP
instances that chain together sequentially. Each provider receives the
output of the previous provider as input, creating a transformation
pipeline.
It changes `Thread::m_frame_provider_sp` to a vector, adds provider
parameter to SyntheticStackFrameList to avoid calling back into
`Thread::GetFrameProvider()` during frame fetching, updated
`LoadScriptedFrameProvider()` to chain providers by wrapping each
previous provider's output in a `SyntheticStackFrameList` for the next
provider and finally, loads ALL matching providers in priority order
instead of just the first one.
The chaining works as follows:
```
Real Unwinder Frames
↓
[13 lines not shown]
[lldb] Add conversions for SBValueList and SBValue to the python bridge. (#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.
(cherry picked from commit 8122d0e4bc8b536e0bb6bb5fae97e8216986ee28)
MIPS: Fix unsigned compare with zero in MipsSEInstrInfo::copyPhysReg (#179866)
SrcRegOff >= 0 is not needed at all for unsigned.
This fixes the warning:
```
llvm/lib/Target/Mips/MipsSEInstrInfo.cpp: In member function ‘virtual void llvm::MipsSEInstrInfo::copyPhysReg(llvm::MachineBasicBlock&, llvm::MachineBasicBlock::iterator, const llvm::DebugLoc&, llvm::Register, llvm::Register, bool, bool, bool) const’:
llvm/lib/Target/Mips/MipsSEInstrInfo.cpp:245:48: warning: comparison of unsigned expression in ‘>= 0’ is always true [-Wtype-limits]
245 | if (SrcRegOff == DestRegOff && SrcRegOff >= 0 && SrcRegOff <= 31)
| ~~~~~~~~~~^~~~
llvm/lib/Target/Mips/MipsSEInstrInfo.cpp:256:48: warning: comparison of unsigned expression in ‘>= 0’ is always true [-Wtype-limits]
256 | if (SrcRegOff == DestRegOff && SrcRegOff >= 0 && SrcRegOff <= 31)
```
(cherry picked from commit 209ff8bf06dd12becd79c1ebb01612c021e19f6c)
[lldb][test] Rename/remove duplicate methods in API tests (#180250)
Ran my python script from
https://github.com/llvm/llvm-project/pull/97043 over the repo again and
there were 2 duplicate test-cases that have been introduced since I last
did this.
Also one of the WASM classes had a duplicate method which I just
removed.
[mlir][vector] Wrapping `populateFlattenVectorTransferPatterns` as a transform pass. (#178134)
This PR covers the `mlir::vector::populateFlattenVectorTransferPatterns`
as a transform pass.
[InstCombine] Fold min/max(fpext x, C) to fpext(min/max(x, fptrunc C)) (#179968)
Fold `min/max(fpext x, C)` to `fpext(min/max(x, fptrunc C))` in cases
where the truncation of the constant is lossless.
This helps eliminate fpext/fptrunc pairs around min/max and addresses
the regression from https://github.com/llvm/llvm-project/pull/177988.
Proof: https://alive2.llvm.org/ce/z/y_Bcdd
AMDGPU: Use fpmath metadata on f16 log/log10 intrinsics
result by default, and the old expansion with the afn flag. The
old result was good enough for OpenCL conformance, so consider
the fpmath metadata and use the fast path. This is done in
AMDGPUCodeGenPrepare for the same reason that sqrt is handled here,
which is the DAG does not have a way to access fpmath metadata
from the original instruction.
This is not yet of practical use, because the log calls sourced
from OpenCL are not actually marked with this metadata and there
isn't a method to produce it from the source languages.
AMDGPU: Use promotion to f32 path for log/log10 for f16 by default
While the current implementation passes OpenCL conformance, it is not
correctly rounded with an error of 1.79 ulp according to the conformance
test. Default to the promotion path without afn. In the future we should
make use of !fpmath metadata but that's not wired into the backend, or
from any frontend producer.
[AMDGPU][GFX12.5] Reimplement monitor load as an atomic operation (#177343)
Load monitor operations make more sense as atomic operations, as
non-atomic operations cannot be used for inter-thread communication w/o
additional synchronization.
The previous built-in made it work because one could just override the
CPol bits, but that bypasses the memory model and forces the user to learn
about ISA bits encoding.
Making load monitor an atomic operation has a couple of advantages.
First, the memory model foundation for it is stronger. We just lean on the
existing rules for atomic operations. Second, the CPol bits are abstracted away
from the user, which avoids leaking ISA details into the API.
This patch also adds supporting memory model and intrinsics
documentation to AMDGPUUsage.
Solves SWDEV-516398.
