[AMDGPU] PromoteAlloca: split scalar accesses that span several elements
promoteAllocaToVector already splits a *vector* access across several
elements when it is a multiple of the element size, but a *scalar* access
had to be bitcastable to the element type, so an i64 load from an alloca
promoted to <8 x i32> was rejected as "not a supported access type" and
the object stayed in scratch.
Accept a scalar access that is a whole multiple of the element size and
route it through the existing subvector path, which already builds the
value from consecutive elements and bitcasts. Accesses with padding are
still rejected, since splitting those would put the pieces at the wrong
offsets, as are non-integer non-float types.
[AMDGPU] PromoteAlloca: flatten homogeneous structs to vectors
getVectorTypeForAlloca() peeled nested ArrayType and one inner
FixedVectorType, but stopped at any StructType. An alloca of an array of
structs was therefore rejected with "Cannot convert type to vector" and
fell back to scratch, even when the struct was a trivial wrapper around a
scalar.
Peel structs too, but only when every field has the same type and the
struct has no padding, so flattened elements keep the byte offsets the
surrounding index arithmetic assumes. Structs with differing field types
or with padding are left alone.
[DirectX] Prevent `dxil-resource-access` from constructing a foldable phi (#211346)
A phi node of the index should only be created if the indices actually
differ: https://godbolt.org/z/x6z64qqvK.
This is resolved by updating `getAccessIndices` to only create a new phi
when needed.
This causes validation errors when accessing specific resources that
require all indices are constant.
Resolves, in part, https://github.com/llvm/llvm-project/issues/211121
Assisted by: Claude Opus 4.8
[X86] combineVECREDUCE_LOGIC - add missing reduce_xor parity result sign extension (#217002)
#199544 enabled support for reduce_xor with non-vXi1 types, but we were
missing the sign extension that was handled only for the reduce_or/and
cases
Fixes #215069
[mlir][Interfaces] `CallOpInterface`: Model forwarded result + improve verification (#214724)
`CallOpInterface` distinguishes between forwarded operands and consumed
operands. This commit adds the concept of "forwarded results", making
operands/results symmetric.
Forwarded operands are forwarded from the caller to the callee's block
arguments. Forwarded results are forwarded from the callee to the
caller's results. All other operands/results are consumed/produced by
the call op.
This commit also improves verification:
- The number of forwarded operands and callee arguments must match.
- The number of forwarded results and caller results must match.
- Verification that was duplicated in op verifiers is now performed by
the interface verifier.
Note: `llvm.call` / `llvm.func` support variadic operands. These are not
supported by `CallOpInterface` or `CallableOpInterface`. The
[8 lines not shown]
[clang] Fix issue introduced in predefined expressions in lambdas (#217021)
Resolves #213420.
The problem introduced in #211811 is that the search for the
`LambdaScopeInfo` corresponding to the current lambda operator stops at
the first scope info that is not a `CapturingScopeInfo`.
This is relevant in `getCurLambda` (where I looked when implementing the
PR), but not here.
[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
[X86] dpbusd tests - presume AVX512BW is available if target has AVX512VNNI (#217020)
Similar to #209838 - technically there's no such target that has
AVX512VNNI but not AVX512BW and there's a limit to "what if" test
coverage we need.
Avoids regressions on future ISD::VECREDUCE_ADD legal support
