[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
[ELF] Handle and optimize x86-64 PLTOFF64 TLS sequences (#216263)
In `gcc -mcmodel=large` generated General Dynamic/Local Dynamic TLS
sequences, R_X86_64_TLSGD/R_X86_64_TLSLD is followed by a MOVABS loading
`__tls_get_addr at pltoff`, and the call goes through a register:
```
leaq x at tlsgd(%rip), %rdi # R_X86_64_TLSGD
movabsq $__tls_get_addr at pltoff, %rax # R_X86_64_PLTOFF64
addq %rbx, %rax
callq *%rax
```
`relaxTlsGdToLe` and `relaxTlsGdToIe` write the 16-byte direct call
sequence at
loc-4, corrupting the preceding instruction, while `relaxTlsLdToLe`
reports
"expected R_X86_64_PLT32 or R_X86_64_GOTPCRELX after R_X86_64_TLSLD".
[3 lines not shown]
[mlir][sparse] Fix crash on linalg ops with buffer semantics (#216458)
Fixes #216215
## The problem
`mlir-opt --sparse-gpu-codegen` crashes on valid input:
```
Assertion `isa<To>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
```
The pass looks for `linalg.generic` ops shaped like a matmul so it can
turn them into GPU library calls. Its checks only look at the *shape* of
the operation (loop count, iterator types, indexing maps, the
multiply-add body) — none of them check whether the operands are tensors
or memrefs.
Sparsity only exists on tensors, so when the pass then asks "is this
[30 lines not shown]
[CodeGenPrepare] Maintain BranchProbabilityInfo up-to-date in bypassSlowDivision (#212058)
The test case crashes on the release/23.x. What happens is the
`BranchProbabilityInfo` becomes outdated because of a change of CFG in
`bypassSlowDivision` but no update to `BranchProbabilityInfo`.
So when it arrives to `SplitIndirectBrCriticalEdges` and hit the assert
in `setEdgeProbability`, because the Branch probabilities no-longer make
sense.
[docs][clang] refactor diagnostic spec instruction and grammar nit (#213432)
A grammar nit found in the description of the Clang Diagnostic Subsystem
is improved.
Replace the instruction mentioning the use of "slash-newline" for
writing multiple diagnostics with the appropriate "backslashes" as that's
what is actually used for separting multiple diagnostics into more than
one line.
The change makes it more obvious on how to implement multi-line
diagnostics by dropping the slightly ambigious slash-newline.
---------
Signed-off-by: Hardik Kumar <hardikxk at gmail.com>
[ARM] Allow tTAILJMPd on v8-M Baseline (#216747)
a1189106d5a1 added B.W to v8-M Baseline, relaxing t2B, tCBZ and tCBNZ
from Requires<[IsThumb2]> to Requires<[IsThumb, HasV8MBaseline]>, and
enabled tail calls for it. It missed tTAILJMPd, which expands to t2B but
still required IsThumb2, so emitting a tail call for a Thumb1 MachO
target failed:
> LLVM ERROR: Attempting to emit tTAILJMPd instruction but the
Feature_IsThumb2 predicate(s) are not met
