[RISCV] Attach VLMAX range attribute for vsetvli/vsetvlimax in InstCombine
Attach a range return attribute to riscv_vsetvli/vsetvlimax so the generic
value analyses can reason about the result via CallBase::getRange(), using the
subtarget's real VLEN instead of the architectural maximum.
VLMAX = VLEN * LMUL / SEW. vsetvlimax returns exactly VLMAX; vsetvli returns
0 <= vl <= min(AVL, VLMAX), which equals AVL only when AVL cannot exceed the
smallest possible VLMAX. Otherwise vl may shrink below VLMAX (to 0 at runtime),
so we only claim the VLMAX-derived upper bound.
Fixes #217784.
Assisted-by: TRAE CLI (Opus 4.8)
Reviewers: efriedma-quic, preames, lenary, lukel97
Reviewed By: lukel97
Pull Request: https://github.com/llvm/llvm-project/pull/218652
[lld-macho] Remove symbol name assumptions from category merging (#217276)
The category merger required every __objc_catlist entry to point to a
symbol named with the `__OBJC_$_CATEGORY_` or `__CATEGORY_` prefix and
hit llvm_unreachable otherwise. Such names cannot be relied upon: `ld
-r` rewrites the names of category body symbols to generated names like
`l002`, and linking its output crashes lld.
The merger also used symbol names to predict the layout of protocol
lists, which is fragile even for conventionally named inputs. The repro
https://github.com/llvm/llvm-project/pull/95124#issuecomment-4267900795
fired the "Protocol list does not match expected size" assertion.
Remove the category symbol name requirement, and drop the layout
assertion together with the SourceLanguage machinery.
[BOLT][RISCV] Implement indirect PLT calls (#219184)
This patch implements `MCPlusBuilder::createIndirectPLTCall` for RISC-V,
enabling BOLT's `--plt=hot` and `--plt=all` optimizations for RISC-V
binaries.
The PLT call pass replaces direct calls and tail calls to PLT entries
with indirect calls through the corresponding resolved GOT slot. The
generated sequence is:
auipc t3, %pcrel_hi(target at GOT)
l[dw] t3, %pcrel_lo(.Lpcrel_hi)(t3)
jalr ra, t3, 0
[WebAssembly] Expand v8f16 SELECT_CC (#218922)
Follow up for #213280 (read
https://github.com/llvm/llvm-project/pull/213280#discussion_r3797603654)
Mark `v8f16 SELECT_CC` for expansion so scalar comparison-based selects
lower through the existing comparison and `v128.select` patterns
[orc-rt] Split headers into support/ and bedrock/ layers. NFC. (#219374)
Follow-up to 8c7563a40a5b, which nested the runtime's headers under
include/orc-rt/bedrock/ and noted that library-neutral headers would
later be split back out.
The split names a layer -- who may include whom. support/ holds
vocabulary and utilities that depend on nothing else in orc-rt; bedrock/
holds the runtime components (Session, Service, the memory map, the
dylib manager, the SPS controller interfaces) and may include support/.
SPIRE will be able to include both. orc-rt-c/ gains the same layering.
Note that support/ is a layer inside the bedrock library, not a separate
one: Error.cpp and RTTI.cpp still compile into orc-rt-bedrock.
Also folded in: bedrock/sps-ci/ -> bedrock/sps/ in both include/ and
lib/; include guards derived from each header's path, as LLVM does
(ORC_RT_SUPPORT_ERROR_H); test/unit/ mirrored onto the new layout, with
cross-layer test helpers left at its root; test-target FOLDER properties
[3 lines not shown]
[mlir][SPIRV] Fix `StorageBuffer` access conversion for emulated i16 (#218693)
Follows up on commit 202ece6. In the absence of `Int16` and
`StorageBuffer16BitAccess` in the target, `i16` isn't any different from
byte & sub-byte types. As exposed by downstream smoke tests of the IREE
project, an edge case where this causes issues is a 0/1-rank memref.
Semantically:
```
memref<i16> -> ptr<struct<array<1 x i32>>>
```
Since the array lengths are the same in the absence of actual packing,
just the index bounds check doesn't catch this and `InBoundsAccessChain`
still gets chosen. In the end, the memref op fails to lower through the
same restriction in `MemRefToSPIRV` that the original change apparently
had to work around - only `AccessChain` is expected there.
As a more general criterion, the change just compares array the element
types and picks `AccessChain` upon mismatch.
[6 lines not shown]
nullfs: Allow VSOCK to be mounted on top of another VSOCK
In the world of containers, mounting a unix(4) socket is a common
practice to allow communication between processes within containers.
For example, both Podman and Docker can expose a unix(4) socket,
and that same unix(4) socket can be mounted as a file accessible
to a process inside a container, allowing that application to control
Podman or Docker. Another example is PHP-FPM with NGINX, where,
instead of using TCP/IP for communication between containers, a
unix(4) socket is sufficient.
However, nullfs(4) and all related components do not allow mounting
a VSOCK on top of another. The current workaround involves creating
the socket in a directory and mounting that directory. This is an
option, though it does not provide a good user experience compared
to directly mounting a VSOCK on top of another, since the application
that creates the socket may create other sockets in that directory,
and the user may not wish to share them, or, worse yet, applications
that create unix(4) sockets may not provide any authentication at
[7 lines not shown]
[X86] Emit adox instead of adc for overflow add (#216609)
ADOX is like ADC but with OF instead of the CF and can only be encoded
with a pair of 32 or 64 bit regs.
Basically this applies in cases where the overflow flag is being added.
[WebAssembly] Select lane stores for floating-point vectors (#219186)
This extends the existing integer vector lane-store patterns to the
equivalent floating-point vector types. The underlying WebAssembly
instructions are type-agnostic lane stores.
That being said I think something like `STORE_LANE_I32x4_A32` can be
misleading when dealing with floating-point vectors. (should there be a
rename or something ?)
[WebAssembly] Fold offsets into extending SIMD loads (#219144)
I saw this TODO and realized that instead of lowering to
```
local.get 0
i32.const 8
i32.add
v128.load64_zero 0
f64x2.promote_low_f32x4
```
We could choose
```
local.get 0
v128.load64_zero 8
f64x2.promote_low_f32x4
```
So I used the existing WebAssembly address operand patterns when
lowering v2f32-to-v2f64 extending loads.
[3 lines not shown]
