[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.
[AMDGPU] Address wave query review feedback
Keep the minimum and maximum waves-per-EU queries together in TargetParser, use the canonical full-SIMD-mode predicate added by the gfx13 LDS changes, and extend coverage for non-splitting and gfx13 targets.
Change-Id: I74a8180e605d6fbf4219d26bc48b2273477db1ec
[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]
[flang] Let -fstack-arrays win over CudaHeapAllocPromotion under mem:unified (#218976)
Example:
```fortran
subroutine foo(n)
integer, intent(in) :: n
real :: tmp(n)
```
Compiled with -gpu=mem:unified -fstack-arrays, tmp still ends up in
malloc_unified: CudaHeapAllocPromotion marks the allocation
fir.must_be_heap, which StackArrays then skips, so -fstack-arrays is
silently dropped. Under mem:unified the stack is device accessible, so
the promotion is a placement choice there. Under mem:managed only the
managed allocator is, so it stays a correctness requirement.
Fix: add a stack-arrays option to the pass and skip the promotion when
it is set and the mode is unified.
