[lldb] Fix DIL losing StackFrame context after casting to pointer (#222386)
When casting to pointer type, `CreateValueObjectFromAddress` is called
with Target context only, so the resulting `ValueObject` doesn't have
StackFrame context anymore, which can cause problems when it is returned
as a final result from DIL. This patch fixes the issue.
[lldb] Speed up `SBValue::CreateValueFromExpression` by using DIL (#222192)
The goal of this patch is to significantly speed up the evaluation of
expressions in the SB API call `SBValue::CreateValueFromExpression`. DIL
is called first and attempts to evaluate the expression, and if it
fails, the function falls back to full expression evaluator. The call to
DIL can be disabled by setting
`target.experimental.use-DIL-for-creating-values` to `false`.
The need for this change comes from `SBValue::CreateValueFromExpression`
often being used in Python data formatters for other projects, where
running the full expression evaluator even for some simple expression
dramatically slows down the entire formatter. The performance overhead
if DIL fails to evaluate the expression is only marginal.
[CIR] Accept `_BitInt` wider than 128 bits in x86_64 callconv lowering (#223069)
With byval in place, a `_BitInt` wider than 128 bits can classify
Indirect and flow through the same byval/sret path as an oversized
aggregate.
That turned up a latent bug, fixed here since it was not reachable or
testable before: the byval/sret pointee type was using the raw declared
width instead of the padded storage width (e.g. `i200` instead of
`i256`), understating the copy size.
Widths whose padded storage integer is not a whole number of 16 bytes,
such as `_BitInt(129)` at `i192`, still have no in-memory layout in CIR
and now reach that gap through the byval and sret pointee instead of
through the classifier. They stay NYI.
Drop the opt-out from the three CIR lit tests gated on this.
Assisted-by: Cursor / claude-opus-5
Depends on #222465
[CIR] Support pointer-to-data-member binary operators for aggregates (#221784)
Implement support for pointer-to-data-member binary operators (`.*` and
`->*`) when the result is an aggregate type.
Issue #221783
[mlir][AMDGPU] Take an `arch` target ID instead of triple/chip/features
`features` was a general `-mattr` string, which needed a general feature
parser and let callers ask for arbitrary combinations we have no interest
in supporting. In practice the only things anyone sets are the wavefront
size and the xnack/sramecc settings that come off a device query.
Replace `triple`, `chip` and `features` with a single `arch` option that
names the target the way Clang does, parsed by `llvm::AMDGPU::TargetID`
rather than by hand. It accepts
- a processor, with optional target-ID modifiers: `gfx942`,
`gfx942:xnack+`, `gfx9-4-generic`;
- a triple: `amdgpu9.42-amd-amdhsa`;
- a full target ID: `amdcgn-amd-amdhsa--gfx90a:sramecc+:xnack-`, which
is what `rocminfo` prints for a device's ISA, so that output can be
pasted straight in.
Since `chipset=gfx942` becomes `arch=gfx942`, migration is a rename.
[22 lines not shown]
[mlir][AMDGPU] Keep `chipset` as a deprecated alias for `arch`
Renaming the option meant every existing invocation of these passes had
to be updated in lockstep. Accept the old spelling instead: `chipset` on
`convert-amdgpu-to-rocdl`, `convert-gpu-to-rocdl`, `convert-arith-to-amdgpu`,
`convert-math-to-rocdl` and `amdgpu-emulate-atomics`, and `chip` on
`gpu-lower-to-rocdl-pipeline`, which is what each of them was called
before the rename.
`arch` wins whenever it names a target; the alias is consulted only when
`arch` is still at the sentinel that means "no target given", so with
neither given the error still names the unusable default rather than an
empty string, and a stale alias value is reported as itself.
[mlir][ROCDL] Carry `arch`'s xnack/sramecc onto the module
`rocdl-attach-target` rejected a target ID that pinned xnack or sramecc,
because `#rocdl.target` feeds a TargetMachine and the backend no longer
accepts those two as subtarget features. Now that the module attributes
exist, migrate them instead of refusing: `TargetInfo` gains
`migrateArchFeaturesToModuleFlags`, which records the settings the target
ID pinned as `rocdl.xnack` / `rocdl.sramecc` on a module, and
`rocdl-attach-target` calls it on each module it attaches to.
A setting the target ID leaves open, or that the GPU does not support, is
left alone rather than written as false: an absent flag means "either",
so writing false would be a different request. That also means an
attribute already on the module survives an `arch` that says nothing
about the feature, while an `arch` that does pin it wins as the more
specific request.
[mlir] Migrate AMDGPU/ROCDL to targets, not chipset versions
**migration tl;dr:** `chipset=` becomes `triple=`, migrate off of
`amdgpu::Chipset` to `ROCDL::TargetInfo`, and eventually change
`gfxXYZ` to `amdgpuX.YZ-amd-amdhsa` in that `triple` argument.
`amdgpu::Chipset` was an awkward hack that was hard to keep up to date
with changes in the compiler/new architectures, and didn't properly
support generic targets (and has been strongly disfavored by the
compiler team).
This PR replaces `amdgpu::Chipset` with `ROCDL::TargetInfo`, a
structure that uses LLVM's TargetParser and the underlying LLVM
features tables to get the real nature of the target being compiled
for.
This also helps MLIR move to
new-style (`-mtriple=amdgpuX.YZ-amd-amdhsa`) over "old
style" (`-mtriple=amdgcn-amd-amdhsa -mcpu=gfxXYZ`) triples.
[40 lines not shown]
[mlir][AMDGPU][NFC] Pre-commit tests for incorrect version checks
There'll be a refactoring from `amdgpu::Chipset` to
`ROCDL::TargetInfo`, thus also moving from chip version checks to
features checks. This commit adds tests for incorrect lowerings that
were allowed by the current code.
- gfx90c is >= gfx90a but stil needs atomic emulation (it doesn't
have buffer fmax and so on).
- gfx90c is also >= gfx90a but has no barrier back-off, so it needs
the inline asm workaround around `s_barrier` that it isn't getting
- gfx908 doesn't have a packed fp16 atomic add but we thought it did
- gfx950 is mistakenly allowing xf32 MFMAs
- gfx1200 is allowing permlane_swap instructions that it doesn't have
- gfx11.7 should be allowing OCP FP8 conversions but isn't on the list
This also cleans up some redundant tests with a --check-prefixes
AI disclosure: Claude found these and wrote the tests.
[2 lines not shown]
[mlir][ROCDL] Add `rocdl.xnack` and `rocdl.sramecc` module attributes (#222444)
Since 27eeb7370281, the AMDGPU backend takes the xnack
and sramecc target-ID settings from the `amdgpu.xnack` and
`amdgpu.sramecc` module flags instead subtarget features, making the
old usage a hard error.
This commit adds `rocdl.xnack` and `rocdl.sramecc` module attributes
to the discardable attribute list the ROCDL dialect defines in order
to represent these flags and adds translations for them.
Omitting them means to leave these modifiers at
their default "either" state, which isn't the same as setting them to
false.
AI disclosure: Claude wrote this code and I reviewed it and tried to
reword the comments to something better.
[RISCV] Consider vmandn.mm in hasAndNot (#223408)
There's a few generic combines that we can take advantage of if we
return true for hasAndNot, e.g. not (setcc x, y, cc) -> setcc x y !cc.
Found with Opus 5
[flang][cuda] do not honor -fstack-arrays in device procedures (#223040)
The device stack is far smaller than the host one, so an automatic array
that fits the host stack easily overflows it. With `-fstack-arrays`
(implied by `-Ofast`) automatic arrays in CUDA Fortran `global` and
`device` procedures were kept on the device stack and overflowed it at
runtime.
Lowering now records a `fir.allocation_policy` with `stack_arrays`
disabled on those procedures, and `getAllocationPolicy` honors a policy
on the enclosing function instead of only the one on the module. The
size based part of the policy is unchanged, so small constant size
arrays still go on the device stack. Host procedures, including the host
copy of `attributes(host,device)`, are unaffected.
[SelectionDAG] Remove dead functions and declarations (NFC) (#223318)
DAGTypeLegalizer::WidenVecOp_ExpOp: Added on April 26, 2023 in commit
eece6ba283bd763e6d7109ae9e155e81cfee0651 without a definition or any
callers.
ScheduleDAGRRList::AddPred: The last uses were removed on April 17, 2019
in commit 258a425c69f0f611ae237ad507252ad18048d2ab when callers were
switched to AddPredQueued.
RegsForValue::append: The last use was removed on January 18, 2019 in
commit 0a45bf0e558e93205a514c856d543fd667099496 when inline asm output
handling was refactored.
Assisted-by: Antigravity
[lldb] Fix batched breakpoint step-over mock (#223000)
This PR fixes the test that printed an `UnexpectedPacketException`
because its mock GDB server did not handle LLDB’s final continue packet.
It adds a normal exit response for that packet and verifies that the
process exits successfully with status zero.
Before:
```
An exception happened when receiving the response from the gdb server. Closing the client...
Traceback (most recent call last):
File "/home/barsolo/llvm-sand/external/llvm-project/lldb/packages/Python/lldbsuite/test/gdbclientutils.py", line
694, in run
self._receive(data)
File "/home/barsolo/llvm-sand/external/llvm-project/lldb/packages/Python/lldbsuite/test/gdbclientutils.py", line
714, in _receive
self._handlePacket(packet)
File "/home/barsolo/llvm-sand/external/llvm-project/lldb/packages/Python/lldbsuite/test/gdbclientutils.py", line
807, in _handlePacket
[28 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.
[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 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
[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.
