[lldb] Skip flaky test_circular_dependency_evaluate_expression_in_get_frame (#213610)
This provider's identity-forwarding pattern intermittently hits a known
frame-identity-aliasing bug in ScriptedFrameProvider::GetFrameAtIndex,
tracked in https://github.com/llvm/llvm-project/pull/208992.
[clang][ast][objc] Implement getNameForDiagnostic for ObjC{Method,Property}Decl (#213030)
This overrides `getNameForDiagnostic` to provide a qualified name
representation for Objective-C methods and properties in diagnostics.
When qualified is true, it formats them using the standard Objective-C
syntax, such as `-[Class selector]` or `+[Class property]`. Previously
these would be `Class::selector` or `Class::property`. If qualified is
false, it falls back to printName.
Note that I avoided modifying `NamedDecl::getQualifiedNameAsString()` or
`printQualifiedName()` which will continue to (unfortunately) return
`Class::method`, but this is intentional to attempt to avoid any
breakage downstream due to output changing.
X86: Defend against regression from SimplifyDemandedVectorElts load support
It doesn't appear possible to test this independently.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
clang/AMDGPU: Add half typed image gather4 builtin
Follow along with the precedent of using an f32 suffix
for the coordinate type. We probably should have had one
builtin that detected the coordinate type.
Co-Authored-By: Claude (Opus 4.8) <noreply at anthropic.com>
clang/AMDGPU: Require 16-bit-insts for half typed image sample builtins
Extend the d16 feature requirement to the half typed image sample
builtins. The sample variants returning 16-bit elements require d16 support
(gfx8+) but were gated only on image-insts/extended-image-insts, so they were
wrongly accepted on old targets.
Co-Authored-By: Claude (Opus 4.8) <noreply at anthropic.com>
clang/AMDGPU: Require 16-bit-insts for half typed image builtins
Typed image load/store operations with 16-bit elements require d16
support which was introduced in gfx8. They were previously gated only
on image-insts, so they were wrongly accepted on targets that have
images but lack 16-bit support (e.g. gfx700), where the backend then
fails to select.
Co-Authored-By: Claude (Opus 4.8) <noreply at anthropic.com>
clang/AMDGPU: Require 16-bit-insts for half typed buffer format builtins
Typed buffer format load/store operations with 16-bit elements require
d16 support which was introduced in gfx8. These builtins previously had
no required features at all, so they were accepted (and then crashed the
backend) on targets without 16-bit support.
Diagnose these in Sema, parallel to the image builtins. The manual
verification here suprised me. The automatic builtin feature verification
is enforced in codegen, which seems like a layering violation which
should be fixed.
Co-Authored-By: Claude (Opus 4.8) <noreply at anthropic.com>
[llvm-calc-occupancy] Fix title underline length (#213599)
Fix error: invalid header length in
'CommandGuide/llvm-calc-occupancy.rst' (does not match length of title)
in our downstream Sphinx doc build.
Enforce single-operand form for llvm.loop.vectorize metadata (#210932)
This patch implements Phase 2 of the RFC "Enforce Single-Operand Format
for All .enable Metadata Nodes". Please refer to RFC:
https://discourse.llvm.org/t/rfc-enforce-single-operand-format-for-all-enable-metadata-nodes/90571/
The two-operand boolean form !{!"llvm.loop.vectorize.enable", i1 0/1} is
replaced by a single-operand enable/disable pair:
!{!"llvm.loop.vectorize.enable"} ; force vectorization
!{!"llvm.loop.vectorize.disable"} ; suppress vectorization
The Verifier rejects the two-operand form, AutoUpgrade rewrites old
bitcode (including the legacy llvm.vectorizer.enable tag), and the
readers and producers across LLVM, Clang, MLIR and Polly are updated.
[GVNHoist] Use MemorySSA, drop MemoryDependenceAnalysis (NFCI) (#212773)
Finalize MemorySSA usage in GVNHoist, while transitioning away from
MemoryDependenceAnalysis.
[MemorySSA] Clarify `getClobberingMemoryAccess(MA, Loc)` overload does not accept MemoryUse (NFC) (#212512)
Outdated comment has been updated to match the implementation, which
asserts on MemoryUse.
RuntimeLibcalls: Add generic FCMP3_F* three-way compare for single-symbol ABIs
MSP430's __mspabi_cmpd/__mspabi_cmpf are one three-way compare symbol serving
every predicate, previously modeled as six suffixed impls each. Replace them
with a single generic operator FCMP3_*, and give softenSetCCOperands a 3rd
lowering option. After the boolean O*_F* and the per-predicate FCMP3_<pred>_F*
helpers, use the generic FCMP3_F* helper tested with the predicate's condition
code.
Also opt __nedf2 out of the MSP430 default set: it was the only libgcc F64
compare not already opted out, so it would otherwise provide FCMP3_UNE_F64 and
win over __mspabi_cmpd for not-equal.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
RuntimeLibcalls: Split soft-float three-way compares into distinct libcall kinds
Soft-float compares come in two flavors. ARM AEABI (__aeabi_dcmpeq) and VFP
(__eqdf2vfp) return a simple 0/1 boolean and use the existing O*_F* / UO_F*
libcalls. The libgcc/compiler-rt helpers (__eqdf2, __ltdf2, ...) return a
three-way -1/0/1, which the legalizer needs to insert the appropriate compare
against.
The three-way helpers previously masqueraded as O*_F* implementations, with the
condition code recovered from a hardcoded switch. Model them instead as distinct
operations. The legalizer then reasons about how to make use of the call result
based on which flavor of operation is available, rather than special casing what
the specific implementation is.
This leaves the mspabi cases for a later cleanup, because it's 3-way usage is
slightly different from the ARM case.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
[flang-rt] enable IsNamelistNameOrSlash lookahead for scalar namelist items (#211224)
Resolves https://github.com/llvm/llvm-project/issues/211747
Problem
-------
An empty NAMELIST assignment on a scalar item — e.g. `l =` in
&nml l= i_count=7 r_value=2.72/
— aborted at runtime with
fatal Fortran runtime error: Bad character 'i' in LOGICAL input field
Every EditIntegerInput / EditRealInput / EditLogicalInput /
EditCharacterInput function starts its list-directed arm with
if (IsNamelistNameOrSlash(io)) return false; // no value
[24 lines not shown]
[OpenMPOpt] Null generic-mode wrappers for SPMDized kernels (#207611)
If a kernel gets SPMDized, it doesn't need the wrapper function that is
passed to __kmpc_parallel_60. Keeping the dead wrapper function can lead
to lots of misleading "local memory global used by non-kernel function"
AMDGPU backend warnings.
Let OpenMPOpt null the wrapper argument such that DCE can then remove
the corresponding dead functions.
Claude assisted with this patch.
[OpenMP][NFC] Document HasAttachPtr semantics in mapper codegen comments
Address review comments:
- Add the struct declarations for the types used by the two worked
examples in emitUserDefinedMapper, so the entry tables can be read
without reconstructing the types from the entry sizes.
- Spell out which entries HasAttachPtr is set on: every entry whose
storage lies in a pointee block, i.e. the combined entry for the
block and the individual member entries that are MEMBER_OF it, but
never the ATTACH entry itself, and never an entry that maps the
pointer as an object in its own right.
Comment-only change.
Co-Authored-By: Claude Opus 5 <noreply at anthropic.com>
Eliminate holding raw shmseg over sleep-window in uvm_unmap
This simplifies the code back to almost the way it was in
rev 1.80 except the shmsegs are changed before any sleep is
possible. This still avoids the double free except via code
structure instead of extra variable carrying the decision.
OK millert@
Reported-by: syzbot+f2c08abe216302bc63d6 at syzkaller.appspotmail.com
[OpenMP] Propagate PRESENT to pointee entries in mapper codegen
Extend map-type-modifier propagation in emitUserDefinedMapper to the PRESENT
modifier, but only for entries that have an attach ptr (the pointee data, whose
storage differs from the struct's own). A present modifier on the outer clause
must require that pointee to be present on the device.
This is gated on a new PropagatePresentToPointee argument, which Clang sets from
CGM.getLangOpts().OpenMP >= 60. Before 6.0 the present modifier is treated as
not applying to the pointee: the spec committee confirmed the divergence
between the present motion modifier (to/from) and the present map-type modifier
(map) was unintentional, to be fixed as an OpenMP 6.0 erratum. Only propagation
is gated; present written directly in a mapper's own clause applies at all
versions.
A TODO notes PRESENT should also propagate to the struct's own members, which
is blocked while pointer members use PTR_AND_OBJ.
Update the present-check tests to their final 6.0-gated behavior.
[2 lines not shown]
[OpenMP][Clang] Enable ATTACH-style maps for mappers.
Track per-entry attach-ptr info (HasAttachPtr) through mapper codegen so that
emitUserDefinedMapper does not add a new outer MEMBER_OF to pointee/combined
entries (which occupy different storage than the struct) or to ATTACH entries.
Clang and the MLIR translator populate the per-entry array in parallel with the
other MapInfosTy arrays.
Address review:
- Rename MapSkipMemberOfArrayTy to MapHasAttachPtrArrayTy to match the
HasAttachPtr field it backs.
- Restructure the emitUserDefinedMapper comment into a bulleted (*)/(**)/(***)
list keyed to the example entries.
- Reword the Clang comments: HasAttachPtr marks pointee entries that have a
base attach-ptr; a combined entry has a base attach-ptr if its constituents
do; cross-reference emitUserDefinedMapper for the MEMBER_OF rationale.
- Update the moved present-check tests to their now-correct behavior (the
attach-style maps make the inbounds present checks pass and remove the
"explicit extension" errors).
[2 lines not shown]
[OpenMP] Propagate ALWAYS/DELETE/CLOSE map-type modifiers to mapper entries (#210210)
Per OpenMP, when a map/motion clause uses a mapper, any
map-type-modifying modifier on that clause applies to each map the
declared mapper specifies.
This change propagates the `ALWAYS`, `DELETE`, and `CLOSE` bits from the
outer clause's map type into every entry emitted by
emitUserDefinedMapper, except `ATTACH` entries (`ATTACH`|`ALWAYS` is
reserved for `attach(always)`, and the other bits have no meaning for an
`ATTACH` entry).
`PRESENT` is intentionally NOT propagated here: it requires
distinguishing pointee entries from the struct's own storage and is
handled in a follow-up.
Co-authored-by: Claude Opus 4.8 <noreply at anthropic.com>
[RISCV][MC] Emit Better Token Diagnostics (#209700)
This implements an old FIXME in the AsmMatcherEmitter, which can now
emit a token-specific match error diagnostic id, and potentially a
token-specific error message to go along with the diagnostic id.
For RISC-V, the overall effect is to have fewer "invalid operand for
instruction" diagnostics and have more "expected '<TOKEN>'" diagnostics,
which, with multiple near miss support, gives the user the location that
token was expected (but not found).
The rejig to the order of checks in `validateOperandClass` do not
prevent backends from having custom operand kinds which can accept
tokens, as was available before.
The TableGen parts have been implemented in an opt-in way.
---
This was implemented with the assistance of AI.
