[AMDGPU] Support global address in V/S_MOV_B64 lowering (#203527)
Hit an issue where V_MOV_B64_PSEUDO had a global, which wasn't
previously handled.
Added support for this, and also for the S_MOV_B64_IMM_PSEUDO to make it
symmetrical.
Claude has been used for this commit, primarily assisting creating a
test.
[AMDGPU] Add threshold for DPP atomic optimizer on LDS atomics (#186762)
Add amdgpu.expected.active.lane metadata which can be applied to operations by a
compiler front-end. Do not apply the DPP atomic optimizer to LDS atomics where
less than five active lanes are expected.
This is an empirically derived threshold based on GFX11 and GFX12 testing.
---------
Co-authored-by: YaFan <YaFan.Tao at amd.com>
[GlobalISel] Fix crash in matchCombineInsertVecElts with INLINEASM-de… (#208225)
…fined base
matchCombineInsertVecElts walks the G_INSERT_VECTOR_ELT chain by
following operand 0 of the source-defining instruction. When the base
vector is defined by INLINEASM, operand 0 is the asm string (not a
register), so calling getReg() triggers an assertion:
Assertion `isReg() && "This is not a register operand!"' failed.
Fix by using the mi_match overload that takes a MachineInstr instead of
a Register, which checks the instruction opcode before accessing any
operands.
[Clang] Fix boolean vector bit counting on big-endian targets (#209146)
`__builtin_ctzg` and `__builtin_clzg` (count leading/trailing zeroes)
can accept boolean vectors as arguments. In this case, they operate in
logical vector lane order. However, `EmitBitCountExpr`, used to generate
the argument to those builtins, bitcasts boolean vectors directly to
integer bitfields, whose bit order is reversed on big-endian targets.
This caused libc's SIMD `find_first_set` and `find_last_set` helpers to
count lanes from the wrong end in big-endian mode. But the issue was
general and could affect any user.
This patch normalizes the integer representation with `llvm.bitreverse`
on big-endian targets before emitting bit-count intrinsics. On top of
that, the codegen test has been refactored to run on more targets and to
cover big-endian mode as well.
As a side effect of this change, and because of the way the code is
structured, the bit reverse operation also happens for
[7 lines not shown]
[CodeGen] Fix incorrect rematerialization rollback order (#197576)
This fixes an issue in the rematerializer's rollbacker wherein adjacent
MIs that were deleted through rematerializations would
sometimes---depending on the exact order in which they were
deleted---not be re-created in their original pre-rematerialization
order. While this does not impact correctness (i.e., use-def relations
are always honored), this goes against the rollbacker's intent to
re-create the MIR exactly as it was pre-rematerializations (up to slot
index changes).
[lldb] Add comma separator in watchpoint description (#209176)
I find it easier to read this way, especially the last "state = enabled type = m" which looks like "enabled type = m" at a glance:
Watchpoint 1: addr = 0xaaaaaaab1018 size = 20 state = enabled type = m
With commas:
Watchpoint 1: addr = 0xaaaaaaab1018, size = 20, state = enabled, type = m
Code breakpoints include commas already:
1: name = 'main', locations = 1, resolved = 1, hit count = 1
1.1: where = test.o`main at test.c:13:15, address = 0x0000aaaaaaaa0714, resolved, hit count = 1
Used the regex "Watchpoint [0-9]+:" to find tests and docs that needed
updating.
NAS-141717 / 27.0.0-BETA.1 / Document HA failover fields on InterfaceEntry (#19299)
Declare the HA-only failover fields (`failover_critical`,
`failover_group`, `failover_vhid`, `failover_aliases`,
`failover_virtual_aliases`) that `interface.query` already emits on
`InterfaceEntry`, and drop the `# FIXME: Please document fields for HA
Hardware`. They previously slipped through only via `extra = "allow"`,
which hid that `interface.query` returns each failover alias with a
`netmask` while `interface.create`/`interface.update` reject it — the
divergence behind the console-menu save failure this documents against.
Documentation/typing only; no behavior change.
[LangRef] State that the memory model is an axiomatic one
Currently, one could read large parts of the memory model without learning for
sure whether it is meant as an operational model that describes how individual
operations change some notion of state or if it is an axiomatic model (like the
C++ memory model) that lists constraints that a candidate execution must
satisfy to be allowed.
While the description of what a read returns sounds somewhat operational,
aspects like the definition of fence instructions, the monotonic modification
order, and the total order of sequentially consistent operations place it in
the realm of axiomatic models.
This is an attempt to make the nature of the model more explicit (and maybe a
place to discuss the nature of the model), as suggested by RalfJung in the
reviews for #204329.
[clang][AMDGPU] Clean-up handling of named barrier type
- Do not allow the type in struct fields. This is more like a handle/resource than a real type. It does not follow the traditional C++ object model, and using it in a struct field can do some weird things if you instantiate too many of them.
- Use a `hip_barrier` LangAS for this type that currently maps to the local AS. This allows easy switching to the barrier AS in a future patch.
Alternative to #195612, see also #195613
