[Clang][Sema] Don't warn on accessing virtual base from abstract class (#217715)
Virtual bases are initialized by the most derived class, and they come
before non-virtual base class initializers. So an abstract class can
assume that virtual bases are already initialized by the time their
constructor runs.
It seems that the warning generally doesn't take indirect bases into
account, otherwise this would become a bit more complicated.
Fixes #204858.
[MemCpyOpt] Don't perform stack-move opt for out-of-bounds copy (#217607)
There can be a copy with an out of bounds offset in dead code. If the
perform the stack-move optimization based on that, we'll end up merging
an alloca into an out-of-bounds offset of another alloca, which will
result in UB (when used in non-dead code).
Fixes https://github.com/llvm/llvm-project/issues/216566.
(cherry picked from commit 8ab2745ce76041a0404c36aea5c37160f10d8840)
[SPARC][IAS] Adjust bounds check in %rX name parsing (#218301)
Fix an off-by-one error that results in %r31 being incorrectly rejected.
This was reported by the folks at OpenBSD.
(cherry picked from commit e013a0f906630d014e04824681b32daa45812c7c)
[MLIR][ODS] Add separator support to oilist (#217891)
Allow an optional literal separator in oilist formats. Parse and print
separators only between present clauses, and diagnose missing, trailing,
and ambiguous separators.
Assisted-by: Codex
[clang][Driver] Fix libc++ include path on FreeBSD (#212725)
`clang++` defaults to `-stdlib=libc++` on FreeBSD. When building with
both `clang` and `libcxx` included, the freshly built `clang++` uses the
system version of the `libc++` headers. However, this is from the
bundled `libc++` 19.1.7, thus inconsistent with the `libc++` being
built.
Similarly to the NetBSD case, FreeBSD has its own version of
`addLibCxxIncludePaths` which just includes `/usr/include/c++/v1`.
This patch removes `FreeBSD::addLibCxxIncludePaths` in favour of the
generic version in `Gnu.cpp`.
Tested on `amd64-pc-freebsd15.1`.
(cherry picked from commit 7f9b3b671718ce555e76b0eb7f728f1e41ca05e2)
[AArch64][FastISel] Avoid TBZ with SLH more thoroughly. (#217329)
With SpeculativeLoadHardening, we already avoid using cond-branch
instructions that don't modify NZCV (CBZ, TBZ), since we rely on NZCV to
propagate the speculative taint mask with CSEL later on.
However, in one case in FastISel, we still emit TBZ, ignoring SLH. Make
it honor the SLH attribute like we do elsewhere.
(cherry picked from commit eb2e28ad666b537837f7ee0ca88f6f66c12d2aeb)
Revert "workflows/release-binaries: Disable flang on Darwin (#164667)" (#216667)
This reverts commit 6d54a5e5b83ce3502b7a3488fea5afe1c8bf9c5c.
Flang Darwin builds were reverted due to #160546. That issue has not
been reproducible (at least on my machine) for several months. There was
a request for MacOS builds on the most recent flang community call.
Flang is not enabled in the MacOS pre-commit CI.
Closes #160546
(cherry picked from commit d2bd0203bee02681b0a150fb8d2d6563b7e56b2e)
[Verifier] Diagnose local scope chains that miss their DISubprogram
DILocalScope::getSubprogram() casts every parent to DILocalScope, so a
DILexicalBlock parented to a non-local scope such as a DIFile makes the
verifier abort on that cast before visitDILexicalBlockBase can report
"invalid local scope".
[clang][NVPTX] Emit !atomic.ignore.denormal.mode for CUDA atomics
CUDA's atomicAdd() family is defined in terms of PTX atom.add, whose
denormal behavior is fixed by the hardware. Without any annotation the
backend has to assume the function's denormal mode must be honored and
expands these into CAS loops whenever the two disagree. Mark them with
!atomic.ignore.denormal.mode so the native instruction is used.
That covers the __nvvm_atom_*_add_gen_f builtins that atomicAdd(),
atomicAdd_block() and atomicAdd_system() are written in terms of, plus
C11/C++11 atomics under -fatomic-ignore-denormal-mode and the
[[clang::atomic(ignore_denormal_mode)]] attribute, which requires
teaching the NVPTX target about AtomicOptions.
The condition for when the metadata is meaningful is now shared with the
AMDGPU and SPIR-V targets in addAtomicIgnoreDenormalModeMetadata(). It
takes an AllowHalf flag because whether f16 denormals are observable is
target specific: PTX exposes no FTZ control for f16 operations, so
atom.add.f16 never flushes and the opt-in is meaningful there, whereas
[3 lines not shown]
[NVPTX] Honor !atomic.ignore.denormal.mode on atomicrmw fadd
PTX atom.add has a fixed denormal behavior that the program cannot
control: atom.add.f32 flushes denormals on global memory but not on
shared, and atom.add.f16 never flushes. When that disagrees with the
function's denormal mode, the backend expands the atomic into a CAS loop
so the denormal behavior is preserved.
!atomic.ignore.denormal.mode says the denormal behavior of this
particular atomic does not matter, so use the native instruction even
when it disagrees. This is the same thing -nvptx-allow-ftz-atomics does,
except per-instruction instead of per-compilation, which lets a frontend
opt in only the operations it knows about -- notably CUDA's atomicAdd(),
which is defined in terms of atom.add.
Note that -nvptx-allow-ftz-atomics defaults to true, so the new behavior
is only observable with -nvptx-allow-ftz-atomics=false.
Co-authored-by: Artem Belevich <tra at google.com>
[IR] Generalize !amdgpu.ignore.denormal.mode into !atomic.ignore.denormal.mode
The !amdgpu.ignore.denormal.mode metadata tells the backend that an
atomicrmw fadd need not honor the function's denormal mode, so a native
atomic instruction whose denormal behavior is fixed in hardware may be
used instead of a CAS loop. Nothing about that is AMDGPU specific: NVPTX
has exactly the same problem with atom.add, whose FTZ behavior depends on
the address space and cannot be controlled.
Promote it to a target independent fixed metadata kind,
!atomic.ignore.denormal.mode, and switch the AMDGPU, SPIR-V and OpenMP
producers and consumers over to it. Document it in LangRef, and point
AMDGPUUsage at that description rather than duplicating it.
Existing IR keeps working: AutoUpgrade renames the metadata on atomicrmw
instructions when parsing textual IR and when materializing bitcode. The
upgrade is deliberately scoped to atomicrmw rather than being applied to
every attachment of that name, since that is the only place the metadata
was ever meaningful. Because bitcode can be materialized one function at
[6 lines not shown]
[SLP] Only reject store chains with too many non-benign outside users (#215700)
This patch rejects store chains with too many non-benign outside users
The previous early reject skipped store chains before costing when
operands had two outside users, even if they were still part of the same
SLP tree (e.g. carry compare and next-limb add). This improved compile
time, but hit runtime performance for multiple use cases. This patch
allows up to two outside users when they look like carry deps (cmp,
select, non-div/rem binop, or two-incoming phi); reject three or more,
or exactly two when at least one is not benign. Also caps the use-list
walk with `UsesLimit`. Precommit test in #217990.
[AArch64] Do not allow anyext load in isEquivalentMaskless (#216288)
isEquivalentMaskless tries to prove that the `and` in `cmp(and(add(x,
C1), 0xff), C2)` is redundant and can be removed, providing that the
input x is know to be a sext or zext. AFAICT it should not apply to
anyext, which could take any value.
Fixes #215839
(cherry picked from commit 90c0c675b463b7aaace2c9f90dfe7fc4f851678c)
[NFC][BoundsSafety] Give `counted_by_or_null`, `sized_by`, and `sized_by_or_null` their own documentation (#212877)
Previously the `counted_by`, `counted_by_or_null`, `sized_by`, and
`sized_by_or_null` attributes all pointed at a single `Documentation`
object (`CountedByDocs`). The generated `AttributeReference.rst`
therefore folded all four into one entry whose text described only
`counted_by` used on a C99 flexible array member.
This was misleading because the attributes differ in important ways that
went undocumented:
* `counted_by` counts *elements* whereas `sized_by` counts *bytes*.
* `counted_by` and `sized_by` require a null pointer to have a zero
count/size, while the `_or_null` variants allow a null pointer
regardless of the count or size.
* `counted_by` may be applied to a flexible array member, but
`sized_by`, `counted_by_or_null`, and `sized_by_or_null` apply to
pointers only.
[34 lines not shown]
[offload] Use pinned memory for KLE
Reduce kernel launch latency by using the fast path "pinned host memory
-> device memory" for submitting the kernel launch environment to the
device.
Claude assisted with this patch.
[offload] Pool host and shared allocations (#214754)
Route them through a memory manager, like the device allocations. Also,
move the registration as pinned memory to the plugin site since only the
plugin knows if the corresponding host/shared memory is pinned. Improves
performance of affected allocations by ballpark 1,000x.
[GVN] Limit MemorySSA reaching-value block scans (#217945)
Cap expensive non-local MemorySSA queries at the same 200-block limit
used by MemDep. On an internal workload, this closes the majority of the
compile-time gap between the MemorySSA and MemDep GVN paths.
Runtime remains almost flat.
[Verifier] Diagnose local scope chains that miss their DISubprogram
DILocalScope::getSubprogram() casts every parent to DILocalScope, so a
DILexicalBlock parented to a non-local scope such as a DIFile makes the
verifier abort on that cast before visitDILexicalBlockBase can report
"invalid local scope".
[MLIR][OpenMP] DeclareTargetInterface and DeclareTargetAttr cleanup, NFCI
The changes introduced by this patch are intended to avoid triggering
multiple by name lookups to the "omp.declare_target" attribute every
time any data from the `DeclareTargetInterface` is queried, remove the
need for keeping multiple default values for the same data, clean up
the assembly format and generally improve the usage of the interface.
List of changes:
- `DeclareTargetInterface` only provides `setDeclareTarget` and
`getDeclareTarget` methods to handle the "omp.declare_target"
attribute, maintaining a single canonical way of accessing it.
- `DeclareTargetAttr` provides direct access to the capture clause and
device type enums, rather than wrapping them into an `Attribute`.
These are now mandatory as well. Both changes together make accessing
them more straightforward and simplify the attribute representation.
[MLIR][OpenMP] Add verification for DeclareTargetInterface (#217294)
This patch introduces checks to ensure the "omp.declare_target"
attribute is only attached to `DeclareTargetInterface` operations, it is
always the right type attribute and its properties do not conflict with
the operation they are attached to.
[MLIR][OpenMP] DeclareTargetInterface and DeclareTargetAttr cleanup, NFCI
The changes introduced by this patch are intended to avoid triggering
multiple by name lookups to the "omp.declare_target" attribute every
time any data from the `DeclareTargetInterface` is queried, remove the
need for keeping multiple default values for the same data, clean up
the assembly format and generally improve the usage of the interface.
List of changes:
- `DeclareTargetInterface` only provides `setDeclareTarget` and
`getDeclareTarget` methods to handle the "omp.declare_target"
attribute, maintaining a single canonical way of accessing it.
- `DeclareTargetAttr` provides direct access to the capture clause and
device type enums, rather than wrapping them into an `Attribute`.
These are now mandatory as well. Both changes together make accessing
them more straightforward and simplify the attribute representation.
[MLIR][OpenMP] Add verification for DeclareTargetInterface
This patch introduces checks to ensure the "omp.declare_target"
attribute is only attached to `DeclareTargetInterface` operations, it is
always the right type attribute and its properties do not conflict with
the operation they are attached to.
[AMDGPU] Handle uniform control flow inside divergent (#217977)
Fix PhiIncomingAnalysis::analyze. When it detected an incoming block
that started divergent control flow ending at DefBlock, it tried to add
all blocks in that divergent region to ReachableMap. But the propagation
could be stopped by other blocks (those that did not start divergent
control flow) that were already in ReachableMap. Fix this by doing the
propagation first, before adding the remaining incoming blocks.
