Add missing opcode for offset validity check (#211186)
During offset validity check, the common API in HexagonInstrInfo does
not handle the opcode. Adding it fixes wherever offset calculation is
made for the instruction.
Co-authored-by: quic-santdas <quic_santdas at quicinc.com>
cp: Correct description of SIGINFO
The manual page claimed that SIGINFO caused information to be printed to
stdout, when in fact it is printed to stderr, as one would expect. This
has been true ever since the feature was first added in 2003.
MFC after: 1 week
Fixes: 00d321a2b395 ("Add a SIGINFO handler.")
Reviewed by: jilles
Differential Revision: https://reviews.freebsd.org/D58392
clang/AMDGPU: Fix handling of subarch only targets with no -mcpu
Extracted this out of the main clang triple conversion patches. This
should be applied to the release branch so you get consistent behavior
if you do build with subarch triples.
[lldb/script] Remove verbose comments following c4962f5721a3 (NFC) (#210827)
This removes verbose comments from c4962f5721a3 following a post-merge
comment.
Signed-off-by: Med Ismail Bennani <ismail at bennani.ma>
(cherry picked from commit e6cde20367a82aca112db73a3d1c76e77fe580f1)
[lldb/script] Only auto-open the generator template in an editor when interactive (#210808)
`scripting extension generate` always launched the external editor after
writing the template to disk, which is fine when a user types the
command at the prompt but is undesirable when the command runs from the
test suite, a headless driver, or a script -- each invocation spawns an
editor that nobody sees.
Extend `--open-editor` (`-e`) so that the default (`eLazyBoolCalculate`)
now dispatches on `CommandReturnObject::GetInteractive()`, which
`SBCommandInterpreter::HandleCommand` explicitly clears. That's the
accurate signal even when the process' stdin is a TTY inherited from the
parent (e.g. `lldb-dotest` invoked from a terminal). `--open-editor yes`
and `--open-editor no` still force the behavior explicitly.
Signed-off-by: Med Ismail Bennani <ismail at bennani.ma>
(cherry picked from commit 3d0f18b6210e8cbc9fa04bca91581e25371c5b14)
[lldb/script] Add scripting extension template generator (#209647)
This patch adds a `scripting extension generate <ExtensionType>...`
command that introspects a Python extension base class and emits a
skeleton subclass with `# TODO: Implement` stubs for its abstract
methods (or, with `-a`, every method), then opens the result in an
editor.
Generated imports use `from <module> import <class>`, and the generated
`__init__` forwards its arguments to `super().__init__(...)` since every
base class relies on its constructor to set up attributes
(`self.target`, `self.process`, ...) that inherited, non-overridden
methods depend on. When the host can't open an external editor (e.g.
non-macOS), the command reports that as a message rather than an error,
since the file is already written.
To catch regressions in the generator itself instead of just checking
that a file was produced, this patch adds
`TestScriptingExtensionGenerate.py`, which generates a template for
[6 lines not shown]
[lldb/script] Migrate frame recognizers onto ScriptedPythonInterface (#209805)
Give `frame recognizer add -l` a formal
ScriptedStackFrameRecognizerInterface, matching the architecture already
used by ScriptedProcess, ScriptedBreakpoint, etc.: a C++ interface
header, a Python-backed implementation built on
ScriptedPythonInterface's CreatePluginObject/Dispatch machinery,
PluginManager registration, and a generatable Python ABC template
(scripted_stackframe_recognizer.py).
get_recognized_arguments' documented contract returns a plain list of
lldb.SBValue (not an lldb.SBValueList), so it bypasses the generic
Dispatch<ValueObjectListSP>() extractor and calls the SWIG bridge
directly, matching the legacy behavior exactly.
ScriptedStackFrameRecognizer now holds a single interface object created
once in its constructor and reused across every RecognizeFrame() call,
same lifecycle as before.
[2 lines not shown]
[lldb/script] Add type hints to scripted extension base classes (#209680)
This patch adds type annotations to every method (parameters and return
types) and every `self.<name>` attribute of the scripted extension base
classes shipped under `lldb/examples/python/templates/`. Extension
authors reading the base classes -- or an IDE navigating them -- can now
see the `lldb.SB*` contract each method exposes without having to
cross-reference the docstring.
`scripting extension generate` also picks the annotations up: derived
class docstrings advertise each inherited attribute together with its
declared type, and the generated method signatures carry their parameter
and return annotations too.
The classes covered are `ScriptedProcess`, `ScriptedThread`,
`ScriptedFrame`, `PassthroughScriptedProcess`,
`PassthroughScriptedThread`, `ScriptedFrameProvider`,
`ScriptedBreakpointResolver`, `ScriptedThreadPlan`, `ScriptedHook`,
`ScriptedPlatform`, and `OperatingSystem`.
[3 lines not shown]
[lldb/script] Improve `scripting extension list` output and filtering (#209400)
This patch improves `scripting extension list` in three ways.
First, it groups the output by `ScriptedExtension`: instead of one row
per registered plugin instance, one entry per extension is printed with
a combined `Language` field.
Second, it colorizes and visually separates the output. Each entry is
preceded by a dimmed dashed separator; field labels are printed in bold
green, the extension name value in bold cyan as a mini-heading, and
`None` usage values are dimmed, all via the same
`ansi::FormatAnsiTerminalCodes(..., use_color)` idiom
`Breakpoint::GetDescription` uses elsewhere, gracefully no-op when color
is disabled or unsupported. `ScriptedInterfaceUsages::Dump` takes an
optional `use_color` parameter so its own `API Usages:` / `Command
Interpreter Usages:` labels can match.
Third, it adds `-j`/`--json` to emit a JSON array of `{name,
[16 lines not shown]
[libunwind][AIX] Handle VAPI-based return addresses in stack unwinding for LLU (#209280)
In AIX's implementation of LLU (Live Library Update), the caller of a
Virtual API (VAPI) interface instead calls VAPI glue and the
implementation for a VAPI function is entered from the VAPI glue. If a
VAPI is not already active on the thread, the VAPI calls the
implementation of the VAPI function with the link register (LR) value
set to a return address in the VAPI glue. In this case, the LR (return
address) value on entry to the VAPI glue is saved in the VAPI control
block. This PR checks whether the return address in a stack frame falls
within the VAPI address range. If it does, the unwinder retrieves the LR
value from the VAPI control block and uses it as the return address
during stack unwinding. In addition, before transferring control to a
landing pad, this PR executes the VAPI return glue to clear the VAPI
control block if the VAPI glue was used.
---------
Co-authored-by: Hubert Tong <hubert.reinterpretcast at gmail.com>
(cherry picked from commit 8aa808457c6aeba25ec0e17139c3fcab59923c3c)
kqueue: Fix delivery of unwanted events
In both procdesc_kqops_event() and filt_proc(), the event variable can
have more than one bit set. This means that:
* We cannot compare it directly with NOTE_EXIT; we must binary-and them
instead.
* We cannot binary-or it with the report mask; we must binary-and it
with the request mask first.
MFC after: 1 week
Fixes: 2a5e58c59694 ("procdesc: add NOTE_PDSIGCHLD")
Fixes: b328975b9d7c ("procdesc: report NOTE_PDSIGCHLD for traced and stopped process")
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D58395
[Matrix] Use incoming terminator as insert point in visitPHI. (#211211)
For some instructions, like invoke, getInsertionPointAfterDef may return
an std::nullopt. Using the insert point after the phi is then incorrect.
Use the incoming terminator as default insert point to fix a crash in
the added test cases.
PR: https://github.com/llvm/llvm-project/pull/211211
(cherry picked from commit 8c556564a2199e13f59dc43bfa5ef4345a89ae3b)
[flang][OpenMP] Add lowering for assume and assumes directives (#205615)
Adds lowering for the assume and assumes directives. holds clauses are lowered to llvm.assume, the other assumption clauses are ignored, and assumes is a no-op. Hints are skipped under -fopenmp-simd.
[Clang][coro] Fix `coro.free` in `.resume` clones with `[[clang::coro_await_elidable]]` (#207799)
Fixes https://github.com/llvm/llvm-project/issues/188230
CoroAnnotationElide rewrites annotated safe calls to the `.noalloc`
variant. The noalloc frame is caller-owned, but its `.resume` clone is
shared with ordinary heap-allocated instances.
With a `suspend_never` final suspend, normal resumption falls through to
the `coro.free` deallocation path. Regular frontend cleanup has already
run before this point. `coro.free` must therefore produce the frame
pointer for a heap instance and null for a `.noalloc` instance.
Use the frame destroy slot as a per-instance allocation tag. Cache its
value at resume entry, before user code can resume and release the
enclosing caller frame, then compare it with the cleanup clone. Replace
each `coro.free` result with the frame pointer for a heap instance and
null for an elided instance.
[5 lines not shown]
[PAC][libc++] Fix build with `ptrauth_calls` feature (#211033)
After partial revert of #208330 in #209928, the libcxx build started
failing because of missing `<cstdint>` include required for `uintptr_t`
declaration used only by code behind `ptrauth_calls` feature check. See
https://lab.llvm.org/buildbot/#/builders/227/builds/3358
This patch adds the missing include.
(cherry picked from commit 12e1c7f70f34d59c023d05d0fe2c228a4e9aac11)
[clang-format][clang-tools-extra] Fix leaking of host-level config into test environment (#206358)
These leaks were causing false test failures due to my global
.clang-format being in an ancestor directory of the build directory.
These changes prevent those issues when running the tests on my system.
I used MiMo v2.5 Pro agentically in Zed to find and fix the issue. But I
understand the changes and judge them to be safe and a clear improvement
over the status quo.
[lldb] Fix Unicode code point formatting to use proper notation (#211131)
- use uppercase hex digits
- only emit "U+" notation for valid code points (<= U+10FFFF),
zero-padded to a minimum of four digits.
rdar://173817553
Assisted-by: claude
(cherry picked from commit 0cd942fa1b6de94fd6d7fa7ba73f0233293115f8)
[RISCV][P-ext] Add packed sign and zero extend intrinsics (#208685)
Add SelectionDAG and intrinsic support for the RISC-V P packed sign- and
zero-extend operations.
Sign-extend is matched through `sext_inreg` (folded from the `shl`/`ashr`
idiom by the generic combiner) and selects to `psext.*`. Zero-extend reuses
the existing `PPAIRE` node with a zero operand instead of a new target node,
since `pzext.* rd, rs` is an alias of `ppaire.* rd, rs, x0`: implementing
`isVectorClearMaskLegal` lets the generic `DAGCombiner::XformToShuffleWithZero`
rewrite the `(and vXi16, 0xff)` / `(and vXi32, 0xffff)` idiom into a shuffle
with a zero operand, which `lowerVECTOR_SHUFFLEAsPPair` folds to `PPAIRE`.
Also adds the LLVM IR intrinsics `llvm.riscv.psext.b`/`.h` and
`llvm.riscv.pzext.b`/`.h`. For RV64 32-bit packed results, the lowering widens
to the legal 64-bit type and extracts the low subvector.
[DTLTO] Forward loop interchange to DTLTO remote compilations (#208591)
Recent upstream LLVM changes enabled `LoopInterchangePass` by default
through `PipelineTuningOptions`. TLTO observes that state directly from
the LTO config, but DTLTO was not forwarding the equivalent Clang option
to the remote compiler. As a result, TLTO could run loop interchange
pass while DTLTO did not, producing codegen differences for
configurations that exposed profitable/legally interchangeable loops.
Note that this was a pre-existing issue, the change in default has
simply exposed it.
Forward `C.PTO.LoopInterchange` as `-floop-interchange` when
constructing the common DTLTO remote compiler options. Extend the
testing to check that the SN-DBS remote command line includes the
forwarded option.
The code for forwarding such options is only intended as a temporary
measure. A more comprehensive solution is in discussion here:
https://discourse.llvm.org/t/synchronizing-lto-code-generation-configuration-between-clang-and-lld-dtlto
[2 lines not shown]
[DTLTO] Add remote compiler option forwarding coverage (#208589)
Add a cross-project DTLTO test that checks the existing LTO
configuration state serialized into the remote Clang command line. The
test uses the validate.py distributor to inspect the generated DTLTO
JSON.
Cover all the existing forwarded options.
Add paired negative checks for optional flags so the test also verifies
they are not emitted when the corresponding configuration state is not
set.
(cherry picked from commit c012610ab9924f465baea5e62397056ea9594567)
[GVN] Support critical-edge splitting in loop-load PRE
When the only in-loop blocker of a loop-load PRE candidate has multiple successors, the reload was placed at the end of that block, so it also ran on the loop-exit edge. Split the critical edge to the unique in-loop successor and insert the reload there, so it runs only on the path back to the header. Bail out on indirectbr or multiple in-loop successors, and keep backedge splitting gated behind the existing flag. Also refresh the stale TODO comments on the freeable-pointer tests, which stay un-PRE'd because the pointer may be freed.
[GVN] Add tests for loop-load PRE into a multi-successor block
Precommit tests for loop-load PRE when the loaded pointer cannot be freed (a gc-managed address-space pointer and a nofree function). PRE currently fires but sinks the reload into a cold block with multiple successors, so it also runs on the loop-exit edge.
[Reassociate] Use UniformityInfo to group uniform operands together (#198507)
On targets with branch divergence (TTI.hasBranchDivergence()), boost the
rank of divergent operands in ReassociateExpression() so they sort
towards the root of the expression tree. This clusters uniform operands
at the leaves, letting the backend lower the inner sub-expression to a
scalar ALU instruction (s_mul/s_or/s_and) instead of a vector.
Ref:
https://github.com/llvm/llvm-project/pull/175167#issuecomment-4476483692
