[mlir][acc] Add map flag for mappings that need no device copy of its descriptor (#232064)
Mapping a variable reached through a descriptor does two things: it
supplies the data's bounds, and it realizes a device copy of the
descriptor so device code can read its `base_addr`. A transform that has
already read everything the region needs from the descriptor on the host
wants only the first, and today there is no way to ask for it. The only
way is to drop the mapping, which discards the bounds too.
`MapFlags::no_device_descriptor` (bit 25) separates them. Keep deriving
the bounds from the descriptor, but create no device copy of it and
attach nothing into its `base_addr`. `computeDataClauseMapFlags` raises
the flag from a discardable unit attribute, `acc.no_device_descriptor`.
Discardable is deliberate and losing the attribute costs only the
suppressed copy, so a pass that does not know about it cannot make a
program wrong.
[llvm-readobj][ELF] Fall back to Address when no single relocation applies
In a relocatable object file, --call-graph-info identifies a function by
the relocation that applies to its address field. If a field had no
relocation, nothing in the output identified the function. If the
relocation section had an invalid sh_link, the dump stopped. If a field
had more than one relocation, the first one was used silently.
In all of these cases, print the value stored in the field as Address,
as for linked files. Warn once if a call graph section has no relocation
section, and warn about each field with no relocation or more than one.
If the relocations can't be read, only that is reported.
Assisted-by: Gemini
[llvm-readobj][ELF] Print Names for call graph relocations
In a relocatable object file, an entry identified by a relocation had no
Names. Compute the address that the relocation resolves to with
RelocationResolver, look up the functions at that address in the section
of the relocation's symbol, and print them as Names before the
Relocation object.
As with Names for an Address, the names follow --demangle. Nothing is
printed for an undefined symbol, or when no function is at the address.
A relocation type that RelocationResolver doesn't support, or a symbol
whose section can't be found, gets a warning.
Assisted-by: Gemini
[llvm-readobj][ELF] Print implicit addends of call graph relocations
A SHT_REL relocation, or a SHT_CREL relocation without explicit addends,
keeps its addend in the field that it applies to. Print the
sign-extended field value as the Addend of such a relocation instead of
dropping it. The ARM test now uses SHT_REL and covers the same cases as
the SHT_RELA tests: named symbols, a negative addend, and a section
symbol with an addend.
Assisted-by: Gemini
[llvm-readobj][ELF] Print a Relocation object instead of Name in --call-graph-info
In a relocatable file, the address fields of a call graph section hold
placeholders, and the relocation that applies to each field identifies
the function. Name showed only the relocation's symbol name, made up
from the section name for an unnamed section symbol, and dropped the
addend. So entries that refer to a function through a section symbol
couldn't be told apart.
Print a Relocation object instead, with the symbol index, the symbol
name exactly as recorded in st_name, and the addend if it is non-zero.
With --demangle, the demangled symbol name is printed as DemangledName.
If the symbol can't be read, the existing warning is reported and only
the symbol index is printed.
Assisted-by: Gemini
[llvm-readobj][NFC] Move the 1-byte call graph info fields last
Group FormatVersionNumber and IsIndirectTarget at the end of
FunctionCallGraphInfo, after the 8-byte-aligned members.
Assisted-by: Gemini
[llvm-readobj][NFC] Match call graph relocations to address fields in one pass
Read the relocations for a call graph section once, sort them by offset,
and attach each one to the address field it applies to while walking the
fields in order. Each field now stores the existing `Relocation<ELFT>`,
so the printing code no longer searches the relocation list for every
field. The call graph structs become templates so that they can hold it.
Assisted-by: Gemini
[llvm-readobj][ELF] Print call graph callees in section order
Keep both the offset and the value of each address field in the call
graph section, and let the printing code pick the one it needs. Later
patches use the offset to look up relocations.
Callees were stored in a SmallSet, which sorts its elements once it
holds more than four, so the output order depended on the number of
callees. They are now kept in section order, and repeated addresses in
linked files are skipped when printing.
Assisted-by: Gemini
[llvm-readobj] Test call graph callees below and above four
Add a function with fewer callees, as the old SmallSet already kept
section order for up to four, and say why main has five distinct
callees. Move main's repeated callee to the end, so that a repeat is
also skipped after the set of seen callees outgrows its inline size.
Assisted-by: Gemini
[llvm-readobj][ELF] Don't clear bit 0 of call graph field offsets on ARM (#230648)
In a relocatable object file, --call-graph-info finds the relocation for
an address field by the field's offset. On ARM, the Thumb bit was
cleared from that offset as if it were an address, so a field at an odd
offset, such as a direct callee, was reported as having no relocation.
Only clear the Thumb bit from addresses.
Assisted-by: Gemini
[lldb-dap] Omit type for variables with no type name. (#231935)
The type field is optional and adding the placeholder `<no-type>`
doesn't add any meaningful information.
rdar://185235160
[clang][NVPTX] Accept only NVPTX GPUs as an NVPTX CPU (#231342)
Accept only NVPTX GPUs as an NVPTX CPU.
NVPTXTargetInfo accepted any name StringToOffloadArch recognizes, so
`-target-cpu gfx906` was a valid NVPTX CPU, and the "valid target CPU
values" note listed the AMDGPU names. It now accepts and lists only
NVPTX GPUs. fillValidOffloadArchList had no other user, so it is
removed.
This also keeps Intel GPU names, added in #229247, from being accepted
as NVPTX CPUs.
[CIR] Fix crash with atomic init in nested region (#231679)
CIR was crashing when a get_member operation is created for an atomic
structure in a nested region, such as a an if statement. The problem is
that we were calling CIRGenBuilderTy::createGetMember while the
enclosing op was still being created (and was therefore disembodied) and
that function was trying to walk back from the current insert location
to the module operation, which it then used to get the data layout.
To fix this problem, I am just passing cir::DataLayout in to the
function as an argument.
Assisted-by: Cursor / claude-opus-5.5
[CIR][OpenACC] Fix crash with nested private (#231666)
When attempting to create a recipe for a private clause in OpenACC, the
first thing we do is get the module op. However, if the builder is in
the process of constructing an operation with its own body region, such
as a if or loop operation, the builder is temporarily in a disembodied
state so trying to walk back from the insert point to the module
operation fails.
This change simply gets the module operation from CIRGenModule.
Assisted-by: Cursor / claude-opus-5.5
[lldb] Let vFile:pwrite write to pipes (#232045)
`vFile:pwrite` could not write to a pipe: pwrite fails with ESPIPE on a
file that cannot seek. The offset means nothing for such a file, so
lldb-server now falls back to a plain write when pwrite reports ESPIPE.
Downstream, NVIDIA's GPU support needs this to attach to a running CUDA
application: the CUDA driver in the application listens on a pipe, and
lldb writes a byte to it through `/proc/<pid>/fd/<fd>` with the `vFile`
packets.
The new test opens a FIFO with `vFile:open`, writes to it with
`vFile:pwrite` at a nonzero offset, and reads back exactly the bytes
sent. Without the fix, lldb-server replies `F-1,1d` (ESPIPE). The test
is skipped for remote runs, since the FIFO and its reader live on the
machine running the tests.
ZTS: test zfs rewrite on an expanded RAID-Z vdev
After a RAID-Z expansion, a block keeps the width of the vdev at its
birth, and with it its data-to-parity ratio. zfs rewrite writes it
again at the width of the expanded vdev, but nothing tests that: the
raidz_expand_* tests never call it, and the zfs_rewrite* tests run on a
single disk. The zpool-attach(8) and zfs-rewrite(8) man pages do not
refer to each other either.
Add raidz_expand_rewrite. It writes a 128K, a 16K and a 4K block to a
5-wide RAID-Z2 with ashift=12 and expands it to 6 wide, checking the
allocated sizes with zdb. Rewritten while the expansion is paused, the
blocks move but keep their sizes (0x36000, 0x9000 and 0x3000), as the
new width only applies to blocks born after the expansion has
completed. Rewritten after it, they are allocated 0x30000, 0x6000 and
0x3000: the 4K block is the same at both widths. Blocks that are
already in the dedup table are found again and stay where they are. The
data is then compared and the pool scrubbed.
[6 lines not shown]
[CIR] Factor CIR module output emission out of CIRGenConsumer (#229441)
No change to generated LLVM IR or object code.
This is preliminary work towards reusing code when
reading `cir` and emitting its output (#227917)
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply at anthropic.com>
[CIR] Fix layout and attributes for non-power-of-two vectors (#230584)
Struct members, array elements and union storage are now laid out by
alloc size, as in LLVM, so a three-element vector takes its full 16
bytes instead of 12. Pointer differences and the x86_64 va_arg stride
use the alloc size too.
The calling-convention pass now places noundef and nofpclass the way
classic does. Each half of a flattened argument keeps the argument's
attributes, except noundef when the coercion widens the value. An
indirect argument's pointer no longer carries nofpclass.
Assisted-by: Cursor / Claude Opus 5.5
[X86][TTI]Make rem paired with same-operand div free (#231661)
A rem with a div on the same operands in the same block shares the
division, for any type and for non-power-of-two constant divisors.
Pricing the rem as a full division let SLP vectorize collapsed-loop
index remainders while the paired divs stayed scalar, adding a vector
division without removing any scalar one (459.miniGhost regression
after #215124).
Assisted-by: Cursor
libzutil: prefer devices of the same pool when fixing up paths
Vdev guids survive 'zpool reguid', so a stale copy of a device, such
as a cloned VM disk taken before the reguid, has the same vdev guid
and path in its label as the device of the reguided pool. fix_paths()
picks the device for a leaf by vdev guid alone, preferring the path in
the config, so the old pool's config is pointed at the new pool's
device: 'zpool import' lists the pool twice, both times with the new
guid and the same device, and the stale copy is never shown.
Record each label's pool guid with its name and prefer devices of the
pool being assembled. Fall back to any device with the vdev guid, as
before, for labels left with different pool guids by an interrupted
reguid.
This makes cli_root/zpool_import/zpool_import_reguid_stale pass.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Will Rouesnel <wrouesnel at wrouesnel.com>
[2 lines not shown]
ZTS: test import listing of a stale device after reguid
Create a pool on a file vdev, copy the file aside, reguid the pool,
and put the copy back. The copy has the old pool guid but the same
vdev guid and path in its label. 'zpool import -d' must list both
pools, with the copy as the old one, and importing the old guid must
give the old pool.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Will Rouesnel <wrouesnel at wrouesnel.com>
Issue #16989
Closes #19316
[GlobalISel] Add nomerge attribute support (#224332)
GlobalISel currently ignores `nomerge`, so BranchFolding is free to
tail-merge calls the source explicitly marked as needing distinct.
Added:
- CallLowering::lowerCall(MachineIRBuilder&, const CallBase&, ...) sets
CallLoweringInfo::NoMerge from CB.cannotMerge(), then scans the
instructions the target just built for the one flagged isCall() and tags
it NoMerge. Generic across targets, unlike SelectionDAG which tags this
per-target in each LowerCall.
- IRTranslator::translateTrap() lowers trap intrinsics outside that
path, so it sets NoMerge explicitly in both of its branches.
Tests added for RISC-V, X86, and AArch64 (calls and tail-calls), plus
X86 coverage for bare-opcode trap intrinsics. The named trap-func-name
form isn't covered: it hits a pre-existing, unrelated GlobalISel
miscompile when two calls share a named callee, independent of nomerge.
Solves https://github.com/llvm/llvm-project/issues/62641
zfs_ioctl: allow read-only channel programs on read-only pools
The channel program ioctl is registered with POOL_CHECK_READONLY, so
the dispatcher rejects every program on a pool imported read-only
before the handler can look at the "sync" flag. That check predates
open-context channel programs and is only needed for programs that
run as a sync task: a read-only pool has no sync thread, so the task
would never complete. A read-only program never assigns a transaction
and cannot call into zfs.sync, so refusing it only stops
"zfs program -n" from inspecting a pool imported read-only, which is
exactly when such inspection is most useful.
Drop POOL_CHECK_READONLY from the registration and have the handler
return EROFS itself when the sync flag is set, which is also the
default when the flag is absent. Sync-context programs behave as
before, while open-context programs now run on read-only pools.
History logging already skips pools that are not writeable. The only
visible difference for sync programs is that invalid limits are now
reported as EINVAL ahead of EROFS.
[7 lines not shown]
ZTS: run channel programs on a read-only pool
Check that on a pool imported read-only, zfs program -n runs a
read-only channel program, while a channel program in syncing context
fails with "pool is read-only" and changes nothing.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Will Rouesnel <wrouesnel at wrouesnel.com>
Closes #19315
[AMDGPU] Tighten mbcnt result range in InstCombine (#232066)
In calculating the valid range of mbcnt calls, current code assumes that
each call contributes masked bit count up to 32. While true, the count
is conservative and could be tightened; only mbcnt_lo on wave64 adds up
to 32, and all other cases add up to 31.
Using these more precise counts allows the range of __lane_id() calls
mbcnt_hi(-1, mbcnt_lo(-1, 0)) to tighten from [0, 65) to [0, 64), a
result of which is to fold redundant bounds checks in HIP's __shfl_xor
(when width is the wave size), eliminating unneeded v_cndmask
instructions. Further detail and original motivation is described in
ROCm/rocm-systems#11618.
The tighter range relies on #227725; without it, this proposed change
caused `mbcnt.hi(-1, 32) & 32` to reduce to 0, so the new test covers
that case. The umin tests that probe the precise upper bound decrease by
one.
Assisted-by: Claude
