[FoldingSet] Switch to linear probing and Algorithm R deletion (#218190)
FoldingSet uses an inefficient chaining hash table. Switch to
linear-probing open addressing: the bucket array holds node pointers,
with null marking an empty slot. Deletion uses Knuth TAOCP 6.4 Algorithm
R, as DenseMap/StringMap do, so erase invalidates iterators while
leaving pointers to nodes valid.
The next-in-bucket pointer becomes a cached 32-bit hash, halving
FoldingSetNode. A probe compares it before the profile compare, and
FindNodeOrInsertPos returns it instead of a bucket address, so an
InsertPos survives intervening insertions.
https://discourse.llvm.org/t/rfc-modernizing-llvms-foldingset-open-addressing-with-swiss-table-and-algorithm-r/91637
LLM-aided
Co-authored-by: Kazu Hirata <kazu at google.com>
[DebugInfo] Add DW_TAG_property support to LLVM DebugInfo (#215776)
DWARF v6 adds DW_TAG_property to represent an entity accessed like a
data member but implemented via an accessor, such as an Objective-C
@property backed by an ivar. This adds a DIProperty metadata node,
plumbs it through the IR (LLParser/AsmWriter, bitcode, DIBuilder,
Verifier), and emits DW_TAG_property/DW_AT_property_forward DIEs in
DwarfUnit, anchored on the accessor's own subprogram DIE.
This covers the LLVM IR and DWARF layers only; Clang emission and
LLDB consumption are left for follow-up patches.
Assisted-by: Claude
[flang][cuda][NFC] Walk fir.call instead of greedy rewrite in CUFFunctionRewrite (#218513)
The pass only replaces on_device() calls with a constant. The greedy
pattern driver was extra work on every fir.call and also folded the
surrounding convert chain. Walk with IRRewriter instead, and check for
the i1 constant in the tests.
This reduce the footprint of the pass especially if there are many
fir.call ops.
[SLP]Fix unscheduled-deps assertion for reassoc scalars covered by another entry's copyable data
The scheduler's reassociated-operand cleanup released the dependency
through copyable data of any entry's edge, so a dep registered for an
uncovered entry could go unreleased.
Fixes: #218850
Reviewers:
Pull Request: https://github.com/llvm/llvm-project/pull/219010
[Clang][CodeGen] Fix crash in EmitParmDecl for bodyless destructors with -fextend-variable-liveness (#218830)
The fake-use coroutine check in EmitParmDecl calls
FnDecl->getBody()->getStmtClass() without guarding against a null
getBody(). This crashes when processing implicit parameters (e.g.
should_call_delete) of MSVC deleting destructors whose base destructor
is only declared, not defined.
[clang][docs] Add documentation for the DanglingPtrDeref checker (#216688)
In order to move the `DanglingPtrDeref` checker out of alpha it needs a
documentation the user can get information from. This PR added the
documentation for the `DanglingPtrDeref` checker and follow up PR will
also do the same for the `UseAfterLifetimeEnd` checker. Currently the
documentation sits in the `alpha.core` category, but once we move the
checker out of alpha stage it should be changed as well.
AI-policy: After I have written the documentation I verified my
spellings, grammar with AI.
[libc][bazel] Allow building with -DLIBC_FULL_BUILD
This PR defines a flag `--@llvm-project//libc:build_mode` that configures LLVM-libc to build with full-build flags. This is only compatible with clang at the moment, since it relies on the `-nostdlibinc` flag.
[libc][bazel] Add a repo with linux kernel UAPI headers
This will be used to support libc's -DFULL_BUILD option, which uses `-nostdlibinc` and thus requires a copy of linux kernel headers.
[VectorCombine] Reject out-of-bounds extract indexes in scalarizeExtExtract (#218984)
Fixes #218724.
An out-of-bounds `extractelement` produces poison in LLVM IR.
`VectorCombine::scalarizeExtExtract` currently matches constant-index
extracts without checking that the index is within the vector bounds.
For a sufficiently large out-of-bounds index, `scalarizeExtExtract` uses
the index to compute a shift amount for the packed integer
representation. The resulting constant can exceed the bitwidth of the
packed type, causing an `APInt` assertion in `ConstantInt::get`.
This patch adds a bounds check in `scalarizeExtExtract` and bails out
when the extract index is out of range, avoiding the invalid shift
construction.
The regression test uses the reduced reproducer from #218724.
Re-apply "[PromoteMemToReg] Insert store undef when removing lifetime markers" (#218935)
Reapplies #191909 / reverts #218804
Re-apply as-is. The issues were downstream and have been since fixed.
lldb: Linux: delete Ptrace.h pollyfill (#218045)
As the comment in sources alludes to:
> System includes - They have to be included after framework includes
because
> they define some macros which collide with variable names in other
modules.
These collisions would ideally not happen, but they are unlikely to be
fixed any time soon. The workaround is to define what we need in the
places that we need it. This was done in a previous commit and so the
header can now be removed.
Link: https://github.com/llvm/llvm-project/pull/217435
Fixes: https://github.com/llvm/llvm-project/issues/217413
[TableGen] Remove unnecessary sorts from writeToStream in InfoByHwMode subclasses. NFC (#218977)
The underlying map is already sorted by mode, so we can iterate over it.
---------
Co-authored-by: Kazu Hirata <kazu at google.com>
[WebAssembly][GlobalISel] Implement pointer and memory ops. (#206885)
Implements a variety of pointer and memory related ops
(`G_GLOBAL_VALUE`, `G_PTR_ADD`, `G_LOAD`, `G_STORE`, etc.).
Split from #157161
-----
TODO (in future PR)
- Move `G_PTRTOINT`, `G_INTTOPTR`, `G_PTRMASK` selection to tablegen
(for all targets)
- MAYBE try to shuffle `G_GLOBAL_VALUE` selection elsewhere (e.g.
legalizer). Doesn't seem worth it?
[DWARF] Add DW_OP_LLVM_NVIDIA_mux vendor extension as a subop of DW_OP_LLVM_user (#216314)
DW_OP_LLVM_NVIDIA_mux takes an LEB128 selector, giving NVIDIA an
extension space behind a single opcode in the DW_OP_LLVM_user space. The
selector is opaque to LLVM; no NVIDIA operation semantics are defined
here. This mux opcode is a subop of DW_OP_LLVM_user.
Assissted-by: LLM
[VPlan][RISCV] Perform a simple version of LSR for EVL tail folded loops
With EVL tail folding the loop step is no longer loop-invariant after vectorization, so SCEV can't analyze it. This prevents LoopStrengthReduce from converting IV-based address calculations to loop-carried phis as before EVL tail folding: https://godbolt.org/z/e3oejca4Y
This adds a *very* simple version of LSR in VPlan that's run for EVL tail folded loops before the step is made unanalyzable by SCEV.
On rva23u64 the following C loop:
for (int i = 0; i < n; i++)
x[i]++;
goes from:
.LBB0_2:
sh2add a3, a1, a0
vsetvli a4, a2, e32, m2, ta, ma
vle32.v v8, (a3)
vadd.vi v8, v8, 1
sub a2, a2, a4
[16 lines not shown]
[libc++][NFC] Add clarifying comment on dangling macro defininition (#215883)
Since we #error immediately before, a comment is needed to explain the
purpose of the define.
