================
@@ -127,13 +145,61 @@ ArgInfo AArch64TargetInfo::classifyArgumentType(
}
reportNYI("Aggregate argument type handling");
- return ArgInfo::getDirect();
+ return ArgInfo::getIgnore();
}
bool AArch64TargetInfo::passAsAggregateType(const Type *Ty) const {
// TODO: Handle SVE types. For now, they don't get through the type mapper.
return isAggregateTypeForABI(Ty);
}
+bool AArch64TargetInfo::isHomogeneousAggregateBaseType(const Type *Ty) const {
+ // Soft-float ABI: no types are homogeneous aggregates.
+ if (isSoftFloat())
+ return false;
+
+ // Homogeneous aggregates for AAPCS64 must have base types of a floating
+ // point type or a short-vector type.
+ if (Ty->isFloat())
+ return true;
+
+ if (const auto *VT = dyn_cast<VectorType>(Ty)) {
+ // TODO: Reject SVE fixed-length data/predicate vectors once the type
+ // mapper can express them.
----------------
madhur13490 wrote:
The TODO here is harmful. `QualTypeMapper::convertVectorType()
(clang/lib/CodeGen/QualTypeMapper.cpp:313-322)` drops Clang's `VectorKind`, so
a 128-bit `SveFixedLengthData` vector reaches this code indistinguishable from
an ordinary NEON vector and is accepted as an HVA member. For `struct {
svfloat32_t a, b; } __attribute__((arm_sve_vector_bits(128)))`, classic CodeGen
returns `<{ <vscale x 4 x float>, <vscale x 4 x float> }>` (a Pure Scalable
Type), whereas this path selects a plain direct HVA return. Could we preserve
the vector kind in `abi::VectorType` (or reject/fall back in the mapper), and
add an end-to-end test?
https://github.com/llvm/llvm-project/pull/218799
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
