[BOLT] Remove ability to use external shell
The external shell is getting removed soon, so remove the ability to
force the use of it within BOLT.
Reviewers:
aaupov, petrhosek, maksfb, yozhu, paschalis-mpeis, yavtuk, ilovepi, rafaelauler, ayermolo
Pull Request: https://github.com/llvm/llvm-project/pull/209567
[Polly] Remove ability to use external shell
The external shell is getting removed soon, so remove the ability to
force enable it for polly tests.
Reviewers: ilovepi, Meinersbur, petrhosek
Pull Request: https://github.com/llvm/llvm-project/pull/209566
[MLIR] Remove ability to use external shell
The external shell is getting removed soon, so clean up the logic here
to enable it.
Reviewers: petrhosek, jpienaar, ilovepi, joker-eph
Pull Request: https://github.com/llvm/llvm-project/pull/209565
[Clang] Drop ability to use the external shell
The external shell in lit is getting deleted soon and it will soon no
longer be possible to force enable it.
Reviewers: compnerd, petrhosek, ilovepi
Pull Request: https://github.com/llvm/llvm-project/pull/209564
[RISCV] Rename VLSU_MEM_LATENCY to Andes45VLSU_MEM_LATENCY in RISCVSchedAndes45.td (#209388)
Prefix the defvar with the Andes45 scheduler name to match the other
Andes45-local defvars (e.g. Andes45DLEN) and avoid a bare, generic name
in the shared RISC-V TableGen namespace.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply at anthropic.com>
[lit] Remove most external shell test coverage
Now that LLVM 23 has branched, we can look at removing the external
shell.
https://discourse.llvm.org/t/rfc-removal-of-the-lit-external-shell/90951
This patch removes most test coverage that was explicitly for the
external shell as it was entirely duplicated with the internal shell.
This patch leaves out removing test coverage in shtest-format as not all
the coverage there is duplicated and it seems like there is some missing
from the internal shell and I want to give it more careful
consideration.
Reviewers: hnrklssn, ilovepi, jh7370, arichardson
Pull Request: https://github.com/llvm/llvm-project/pull/209500
[CIR] Fix x86 builtin tests after tighter inlining (#209653)
The behavior of the AlwaysInliner was tightened in a recent change
(https://github.com/llvm/llvm-project/pull/209345) to avoid inling
functions with mismatched target attributes even when the alwaysinline
attribute was present. This exposed a few failures in CIR where we were
either running with stale target features or missing target features
that were needed for the builtins we were testing.
This change updates the run lines to use the correct feature sets.
[MetaRenamer] Change basic block naming from 'bb' to 'bbl' (#205393)
Currently, `update_test_checks.py` warns when run on MetaRenamer output
e.g., `WARNING: Change IR value name 'bb3' or use
--prefix-filecheck-ir-name to prevent possible conflict with scripted
FileCheck name.`
Avoid this conflict by changing MetaRenamer to use 'bbl' for basic
blocks.
This is similar in spirit to
https://github.com/llvm/llvm-project/commit/86a63b2ae147e5a3edc39643783acfd39b059c92,
which renamed instructions from 'tmp' to 'inst' to avoid a conflict with
automatically-generated checks.
[BOLT] Stop materializing .dwo DIE vectors early in the pipeline
Summary: preprocessDWODebugInfo() eagerly force-extracted every .dwo
compile unit's DIE tree (getNonSkeletonUnitDIE(false)) very early in
BOLT pipeline, way before DWARFRewriter kicked in. Those vectors then
sit in memory throughout the entire rewrite pipeline, directly
contributing to BOLT's RSS peak. I did a fair amount of digging and
didn't find any reason as to why we need to keep all DIEs of DWO CU
materialized at all, since DWARFRewriter won't even read this vector
(the #197359 concurrency fix did use that, but that is unnecessary).
The problem is that these DIE trees are a massive contribution to RSS
when processing large binaries where we have 10s of K of dwos, storing
complete trees for each processed dwo.
This diff changes the #197359 concurrency fix to not rely on the DIE
sibling/children structure. It parses DWP type units selectively per
compile unit (DIEBuilder::buildDWPTypeUnitsForUnit ->
collectReferencedTypeSignatures) by finding the DW_FORM_ref_sig8
references in a unit's DIEs to decide which type units belong in that
[23 lines not shown]
[lldb] Add MCP tools to create and destroy debugger instances (#209288)
Add debugger_create and debugger_delete tools to the MCP server so a
client can manage debugger instances, not just command the ones that
already exist. debugger_create detaches the new debugger's stdio from
the host process (redirecting input/output/error to the null device) so
its prompt and asynchronous output cannot corrupt an MCP stream that
shares the host's stdout. Command results flow through
CommandReturnObject and are unaffected.
Factor the tool and resource registration out of
ProtocolServerMCP::Extend into a shared PopulateServer() so an embedded
in-process server (e.g. in lldb-mcp) can install the same set.
Assisted-by: Claude
rdar://181722721
[BOLT] Fix shifted DWARF inline-scope ranges; track scope boundaries (#207291)
Summary:
BOLT updated DWARF lexical-scope ranges (DW_TAG_inlined_subroutine /
lexical_block low_pc/high_pc and DW_AT_ranges) via
translateInputToOutputRange(), which mapped a boundary using its input
offset relative to the start of the containing basic block:
OutAddr = BB.getOutputAddressRange().first + (InputOffset -
BB.getOffset())
This assumes intra-block byte offsets are preserved input->output. Any
pass that changes instruction sizes within a block ahead of a scope
boundary breaks that assumption. With --plt=all, each `call foo at PLT` (5
bytes, e8+rel32) is rewritten to `call *foo at GOT(%rip)` (6 bytes, ff
15+rel32); N such calls before a boundary shift its emitted low_pc/
high_pc N bytes too early, onto the preceding instruction. The range
stays within the parent so `llvm-dwarfdump --verify` does not catch it;
symbolizers then attribute samples on those instructions to the wrong
[44 lines not shown]
[lldb] Use std::atomic<bool> for Editline's pending-resize flag (#209619)
TerminalSizeChanged() used a volatile std::sig_atomic_t to record that a
resize is pending. That type was chosen because the SIGWINCH handler ran
in async-signal context and could only touch an sig_atomic_t. Signals
are now handled on a dedicated thread, so the flag is written from a
normal thread and std::atomic<bool> is sufficient to handle that.
el_resize() still runs on the thread that owns libedit, in its read
loop. I discovered that it is not safe to run elsewhere, because it
resets libedit's display model without redrawing. Applying it off that
thread seems to throw it off and makes it duplicate the prompt.
[lldb][test] Deflake the statusline scripted-command output test (#209643)
test_scripted_command_output_not_eaten failed intermittently in CI on
its assertIn(b"\x1b7", data) guard because the captured window held no
statusline escape at all, only the command output and the next prompt.
The cause is a thread-scheduling race, not a bug. The statusline is
redrawn on the event thread once per progress event, but on a loaded
machine the event thread need not run until the flood command has
already returned, so it drains the queued progress events after (lldb)
was matched and the capture stopped, leaving no redraw to inspect.
Widen the flood (the line count is now an argument) so the event thread
has a larger window to redraw in, and retry until at least one complete
cursor save/restore pair is observed before checking that no output was
spliced into it. If a redraw is never seen, skip rather than fail.
I deliberately avoided a per-line sleep as it would let each redraw
finish between prints and hide the very interleaving the test looks for.
Fixes #209605
[msan][NFCI] Add forceIntegerIntrinsic option to handleIntrinsicByApplyingToShadow() (#207053)
Currently, if handleIntrinsicByApplyingToShadow() is given an
IntrinsicInst with floating-point arguments, it will cast the shadows to
floating-point, apply the intrinsic, and then cast the result back to
integer/shadow. This is inefficient, and, depending on the intrinsic,
may also result in floating-point exceptions.
The user can explicitly supply an integer variant of the intrinsic to be
applied to the shadow (shadowIntrinsicID), but this does not work if the
integer and floating-point variants are overloaded forms of the same
intrinsic ID.
This patch adds an option, 'forceIntegerIntrinsic', which will pass the
shadows as integers to the intrinsic, thus avoiding unnecessary casts.
(This is not enabled by default since some intrinsics do not support
integer arguments.)
As an example, future work can use 'forceIntegerIntrinsic' to handle
[4 lines not shown]
[msan][NFCI] Add AVX512 DQ tests (#207059)
This adds tests for AVX512 DQ ("Doubleword and Quadword Instructions",
not to be mistaken with Dairy Queen), forked from
llvm/test/CodeGen/X86/avx512dq-intrinsics.ll.
[lldb] Distinguish DWARF binary type-check error messages (#209644)
CheckScalarOperandsHaveSameType reported every operand-check failure
with the same "requires operands to have the same type" message, even
though it rejects operands for three different reasons: mismatched type
kind, mismatched size, and mismatched signedness. That made a failed
check hard to diagnose from the error alone.
Parameterize the message so each check names what actually differs
(type, size, or signedness).
Follow-up to Augusto's review of #209641.
[analyzer] Disable lock order reversal check by default in PthreadLoc… (#202452)
…kChecker
Lock order reversal is a real source of deadlocks, but the current
single-path intraprocedural analysis is a single-path analysis, and it
cannot reason about potentially overlapping executions.This makes this
part of the checker too imprecise for default-on.
Add a WarnOnLockOrderReversal option (default: false) for the previous
behavior.
[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,
[14 lines not shown]
Thread Safety Analysis: Handle statement expressions in try-lock conditions (#209330)
Previously, statement expressions (`({ bool b = mu.TryLock(); b; })`)
used as try-lock conditions were not supported. Handle StmtExpr in
getTrylockCallExpr() by recursively analyzing the last statement of the
statement expression.
