[AMDGPU] Canonicalize num_records to its actual width in InstCombine
llvm.amdgcn.make.buffer.rsrc is overloaded on the type of its
num_records argument, but the hardware field it ends up in has a fixed
width (32 bits, or 45 bits on gfx1250 and up). Rewrite the intrinsic to
use that width, zero-extending or truncating num_records as needed, so
that IR-level optimizations can see that the extra bits of, for example,
the i64 that Clang emits are not demanded.
Targets that aren't concrete enough for the buffer resource layout to be
known are left alone.
AI disclosure: This was my idea but Claude wrote the code (and I've
tried to tighten up the comments)
[AMDGPU] Pre-commit tests for num_records canonicalization
Add tests for having InstCombine canonicalize the num_records argument
of llvm.amdgcn.make.buffer.rsrc to the width it will ultimately have,
which lets later passes see that, for example, the high bits of the i64
that Clang emits aren't used.
AI disclosure: Claude generated these and I've looked at them
DAG: Fix null dereference in visitABD for poison constant elements
visitABD calls ISD::matchUnaryPredicate with AllowUndefs=true, which
passes a null ConstantSDNode to the predicate lambda for each undef or
poison element.
Co-authored-by: Claude (Claude-Opus-4.8)
PowerPC: Fix MI peephole crash on an undef forwarding operand (#216685)
Found by AI while working on something else.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
Pull up following revision(s) (requested by tls in ticket #436):
sys/arch/evbmips/malta/pci/pcib.c: revision 1.29
sys/arch/evbmips/malta/dev/mainbus.c: revision 1.21
sys/arch/evbmips/malta/dev/gt.c: revision 1.20
sys/arch/evbmips/malta/malta_intr.c: revision 1.30
sys/arch/evbmips/malta/malta_bus_mem.c: revision 1.10
sys/arch/evbmips/malta/machdep.c: revision 1.51
sys/arch/evbmips/malta/malta_bus_io.c: revision 1.9
sys/arch/evbmips/conf/MALTA: revision 1.107
Address problems with MIPS Malta platform code found running under QEMU.
QEMU's "malta" system emulates a MIPS Malta with the Gallileo host bridge
and 32-bit or 64-bit CPUs of either endianness. It is one of the only
working QEMU system-level emulations that could run NetBSD with all
combinations of endianness and address size. After fixes to QEMU over the
past several years, NetBSD has been unable to use the emulated PCI bus in
big-endian and 64-bit configurations.
[36 lines not shown]
[mlir][LLVM] Use a disjoint scope domain when inlining noalias
This matches recent changes to the LLVM inliner.
AI disclosure: Claude wrote the code, I wrote the commit message and
have done initial review.
[AMDGPU] Use a disjoint scope domain for merged LDS structs
When lowering LDS values, all the values are mutually disjoint, so we
can use the newly-added disjoint scopes feature to simplify the IR.
AI disclosure: Claude wrote this and I reviewed it and wrote the
commit message
[mlir][LLVM] Add disjointScopes to AliasScopeDomainAttr
This also updates the MLIR-side inliner to clone disjoint domains
while cloning alias scopes, matching changes to LLVM.
AI disclosure: Claude wrote the code, I wrote the commit message and
looked at the code.
[AMDGPU] Use a disjoint scope domain for noalias kernel arguments
All noalias arguments of a kernel are disjoint with each other, so we
can use a disjoint scope to save on metadata construction.
AI disclosure: Claude wrote this, I looked at it and wrote this
message.
[Inliner] Use a disjoint scope domain for noalias arguments
InlineFunction creates alias.scope/noalias metadata to represent the
set of `noalias` arguments to a function. We don't need the `!noalias`
now that we have the ability to use disjoint scopes, saving us IR size
and metadata bloat.
TODO move these to a previous commit.
Also changes InstCombine to not drop the experimental.noalias.scope.decl
for disjoint scopes even if they're not mentioned in a `!noalias`, but
do still delete them if they're not used.
[IR] Add alias scope domains with disjoint scopes
See RFC at
https://discourse.llvm.org/t/rfc-disjoint-scope-alias-scope-noalias-domains/91537
This commit adds support for declaring an alias scope domain disjoint.
Disjoint domains are ones where each scope is implicitly `!noalias`
with each other scope in the domain. This is represented by adding an
`i1` into the scope's domain as the second argument, with `i1 true`
representing disjoint scopes and `i1 false` representing the old
non-disjoint behavior. AutoUpgrade mechanisms have been added to add
in the missing `i1 false` to existing metadata.
This commit updates alias analysis to know about disjoint scopes and
updates the function cloner to also clone the alias domain if it's
disjoint (since, as a herd of LLMs discovered, you don't want the old
IR to be noalias with a clone of itself).
Commits to migrate passes to use disjoint scopes where that's an
[4 lines not shown]
[utils] Don't rename %. inside quoted strings in test checkseg
Replacing `%.foo` with `%dotfoo` everywhere also caught any `%.foo`
inside metadata, which would then cause incorrect CHECK lines to be
generated (since the value in the metedata isn't going to be
modified).
This commit fixes the issue by matching quoted strings in a regex
before looking for %. to replace.
AI disclosure: Claude found and fixed this, I wrote the commit message
Add -use-fortran-assign-only fallback test for both assign paths
Verify that the -use-fortran-assign-only flag forces both the
allocatable and non-allocatable array paths to use _FortranAAssign
instead of _FortranAAssignSimple, preventing regression of the
fallback logic.
Co-Authored-By: Claude Opus 4 (1M context) <noreply at anthropic.com>
Factor out genAssignSimple vs genAssign selection into a lambda
The logic for choosing between genAssignSimple and genAssign was
duplicated in the allocatable and non-allocatable paths of
AssignOpConversion. Extract it into a genSimpleOrAssign lambda to
avoid code drift between the two paths.
This also fixes the allocatable path which was missing the
useFortranAssignOnly guard that the non-allocatable path had.
Co-Authored-By: Claude Opus 4 (1M context) <noreply at anthropic.com>
[flang] - Call _FortranAAssignSimple instead of _FortranAAssign for intrinsic-type array assignments.
This patch adds support for calling _FortranAAssignSimple, a faster-path for array assignments.
`_FortranAAssignSimple` is called when ALL the following conditions are true:
1. Intrinsic element type (not derived type)
2. Matching ranks (no scalar-to-array broadcasting)
3. Non-volatile
4. Not polymorphic
5. Not explicit-length character
6. Not temporary LHS
Otherwise, uses `_FortranAAssign` (or specialized variants like `_FortranAAssignPolymorphic`, `_FortranAAssignExplicitLengthCharacter`).
This is a (perhaps final) part of the fix for https://github.com/llvm/llvm-project/issues/203915
[flang-rt] - Lightweight runtime assignment function (AssignSimple) for intrinsic-type assignments (#213704)
This PR introduces a lightweight assignment runtime path
(`_FortranAAssignSimple`) for intrinsic-type arrays with the goal of
reducing compile-time overhead seen primarily in the form of severly
increased time taken by LTO. This PR includes only the changes to the
runtime (flang-rt) and as such just with this PR compile-time
improvements will not be visible.
**Problem**
When compiling Fortran code with OpenMP GPU offload and
`firstprivate(allocatable_array)`, LLVM's Attributor creates excessive
abstract attributes analyzing complex runtime assignment machinery:
**Symptom:**
- **Test case:** 8-element allocatable integer array with `firstprivate`
clause
- **Compile time:** 24.97s (vs 0.78s for `private` - **32x slower**)
[61 lines not shown]
[CIR] Lowering __builtin_stdc_* calls (#214931)
Added CIRGen support for __builtin_stc_* , matching with the C23 stdbit
semantics.
Added CodeGen test for the same.
Fixes #214443
[AMDGPU] Configure the software pipeliner policy
Set the pipeliner policy in overridePipelinerPolicy() to opt into the generic
register-pressure detector.
Schedules exceeding the target-provided pressure-set limits are rejected and
retried at a higher II.
