[Attributor][NFC] Get the associated value of a call site argument from its use (#240919)
For a call site argument, `getAssociatedValue` computed the operand
number from the use only to look the operand up again. Use the value of
the use directly.
CTMark with `-attributor-enable=light`: -0.19% (O3), -0.20% (ThinLTO).
Co-authored-by: Matt Arsenault <Matthew.Arsenault at amd.com>
Assisted-by: Claude Opus 5.5
[lldb] Make darwin-mte-launcher die from its program's signal (#239873)
When the program the launcher spawns is killed by a signal, the launcher
returns `WEXITSTATUS(status)`, which is 0. A crash under the launcher
then looks like a clean exit, so the shell and API tests that run lldb
through it can't tell that lldb crashed.
This patch makes the launcher re-raise the program's signal so callers
see the crash. It first restores the signal's default action and
unblocks it, since the launcher inherits both from its parent.
The program already had its chance to report the crash, so before
re-raising, we clear the launcher's `EXC_MASK_CRASH` and
`EXC_MASK_CORPSE_NOTIFY` exception ports to avoid a second crash report.
Clearing `EXC_MASK_CRASH` alone, as LLVM does for
`LLVM_DISABLE_CRASH_REPORT`, still lets the system write a report. We
only do this once the program has exited, because the program would
otherwise inherit the ports.
[2 lines not shown]
[RISCV] Use std::optional for riscv-max-build-ints-cost command line option (#240976)
This seems more sensible than giving a value of 0 a special meaning. A
explicit value of 0 will be treated as 2 now rather than using the load
latency.
[lldb] Recognize signal trampolines from CFI before unwind-plan selection (#237016)
Signal dispatch can install a return address at the first instruction of
a trampoline without a preceding call. If the trampoline is not
recognized by name, LLDB can back up that address into the preceding
function before finding its signal-frame CFI.
Extend trap-handler detection to consult .eh_frame as well as platform
and user-provided names. CFI-recognized handlers use the existing
trampoline-entry exception and trap-handler plan selection. Test
recognition without target.trap-handler-names, retain name-only
coverage, and check that a real call inside a signal-marked function
uses the call-site row when the return PC starts a terminal row.
Assisted-by: GPT
[TargetParser] Return 2 as default wchar_t size for AVR and MSP430 (#240620)
Both are 16-bit targets where clang defines wchar_t as a 16-bit int, but
Triple::getDefaultWCharSize() returned 4 for them. Return 2 for all
16-bit targets, which should be a safe assumption.
Assisted-by: Claude
[BPF] Wrap both cross-BB icmp conditions in BPFAdjustOpt (#231257)
In `BPFAdjustOptImpl::serializeICMPCrossBB`, only `B1`'s branch
condition was wrapped in `@llvm.bpf.passthrough.i1.i1`, leaving `B2`'s
branch condition unwrapped. Because `foldBranchToCommonDest` in
`SimplifyCFG` only checks that `B2`'s branch condition is a `CmpInst`,
`SimplifyCFG` still merged `B2` into `B1` using a `select`. After
3b5fbbd0b5f8 (#226297), `ConstraintElimination`'s `addInfoForInductions`
matched the unwrapped `B2` `icmp` in the merged `select` condition,
deduced a loop header bound on the induction variable, and folded `B1`'s
upper-bound `icmp` to `true` inside `@llvm.bpf.passthrough.i1.i1`,
causing the BPF verifier to reject valid loops.
Additionally, `serializeICMPCrossBB` previously started from a successor
of `B2` via `BB.getSinglePredecessor()`, causing it to match the same
`(B1, B2)` pair twice when both successors of `B2` had `B2` as their
single predecessor.
Fix `serializeICMPCrossBB` to treat `BB` as `B2` directly and wrap both
[3 lines not shown]
[AMDGPU] Reduce resource align when shrinking buffer loads (#240945)
Since the `align` on buffer intrinsics includes the offset argument,
the demand, `simplifyAMDGCNMemoryIntrinsicDemanded` needs to account
for the value added to that offset, which might reduce the alignment
of the load.
This was *technically* a miscompile before, but it never come up because
this information was never used in codegen.
AI disclosure: Claude wrote the code, I looked at it and wrote the
commit message.
RuntimeLibcalls: Add missing attributes to memory and allocator libcalls
Add the attributes inferLibFuncAttributes would give these functions.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
RuntimeLibcalls: Move malloc, calloc and free attributes to TableGen
This requires new attribute plumbing for attributes that have an
argument value.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
ARM: Define the R12 register class explicitly (#241005)
TableGen inferred the R12-only class from hGPR and tcGPR, and it
inherited the Thumb1 allocation order of tcGPR, which only has low
registers. On Thumb1 the class had no allocatable registers, so an
inline asm input tied to r12 failed to allocate. In the future
TableGen should error on allocatable classes without any members.
Define the class explicitly so R12 is in its allocation order. This
fixes a regression from #238705, which started creating tied inline
asm inputs in this class.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
RuntimeLibcalls: Move malloc, calloc and free attributes to TableGen (#240713)
This requires new attribute plumbing for attributes that have an
argument value.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
Adjust fontconfig's default preference order to prefer Bitstream Vera
and Liberation fonts over the Luxi Type1 fonts, which freetype struggles
to render. Helps make the default text rendering better in e.g.
GTK applications and web browsers.
XXX this change also needs to happen in pkgsrc.
PR xsrc/60991: fontconfig prefers Luxi Type1 fonts for Latin text, which
are extremely ugly
[AMDGPU][GlobalISel] Fix immediate offset overflow when splitting s.buffer.load
When we're splitting a very large (>128 bit) s.buffer.load into
128-bit buffer loads, we add offsets to each split load. Currently,
when dealing with ptr.s.buffer.load, the code wouldn't subtract enough
from the immediate offset, so that when we added that +128 or +256,
we'd overflow the 12-bit immediate, causing silent overflow.
This commit fixes the issue by correctly calling the offset
splitter with a "alignment" that ensures that all those intermediate
loads don't overflow.
This matches the behavior in SDag and RegisterBankInfo.
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
[AMDGPU][GlobalISel] Pre-commit tests for split s.buffer.load offset overflow
Add divergent-offset ptr.s.buffer.load tests where the 256- and 512-bit
loads are split into 128-bit pieces at an offset of 4092, causing
overflow on the immediate field.
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
limit the number of keyboard-interactive devices accepted to 100,
avoiding a small CPU DoS in sshd-auth (mitigted by MaxStartups and
PerSourcePenalties).
Reported by Lei Li (李磊) and Zhongke Guyuan (中科固源)
ok markus@
[NvlinkWrapper] opt-remarks-filter -> opt-remarks-passes
`renderRemarksOptions` in Clang's `CommonArgs.cpp` translates
`-foptimization-record-passes` to `--plugin-opt=opt-remarks-passes`.
`lld` expects that, but `clang-nvlink-wrapper` currently expects
`--plugin-opt=opt-remarks-filter` instead, producing errors like:
```
clang-nvlink-wrapper: Unknown command line argument opt-remarks-passes=inline
```
In `NVLinkOpts.td` for `clang-nvlink-wrapper`, this patch adds
`--plugin-opt=opt-remarks-passes` and makes
`--plugin-opt=opt-remarks-filter` an alias. If there are no users of
the latter, we can consider removing it.
Assisted-by: LLM
[CIR] Implement 'dsoLocal and 'protected visibility' (#240985)
This patch implements the setDSOLocal and protectedVisibility missing
features. These are both required to get the 'dso_local' to show up
correctly on RTTI members and to get their visibility correct.
Previously, we approximated it based on the MLIR public/private-ness,
but this doesn't take into account the visibility attribute, nor RTTI
correctly.
This patch adds that, and adds testing for all of the places this
changes. However, note that LLVM-IR will not print dso_local if it is
'implied' so it wasn't as obvious that it was not correctly marked in
CIR (but LLVM-IR effectively 'got it right').
Additionally, mlir default-sets declarations as 'private', so we were
missing a few cases where the linkage wasn't being set properly. This
patch ALSO updates those. This again is something that doesn't really
end up in the LLVM-IR, just in the MLIR types however, so it isn't
really visible, just another 'correctness' fix.
