[clang] [Clang][RISCV] Handle RVV tuple types correctly as OutputOperands for inline asm (PR #67018)
Yueh-Ting Chen via cfe-commits
cfe-commits at lists.llvm.org
Sun Sep 24 23:34:11 PDT 2023
================
@@ -2524,11 +2551,32 @@ void CodeGenFunction::EmitAsmStmt(const AsmStmt &S) {
ResultRegIsFlagReg.push_back(IsFlagReg);
llvm::Type *Ty = ConvertTypeForMem(QTy);
+ ResultTruncRegTypes.push_back(Ty);
+
+ // Expressing the type as a structure in inline asm calls will complicate
+ // the current code case, so instead, the return type is set to be a
+ // single scalable vector, then reconstructed with `vector.extract` and
+ // `insertvalue`. The type is derived here, and the reconstruction is done
+ // under EmitAsmStores.
+ if (QTy->isRVVType() && isa<llvm::StructType>(Ty)) {
+ // Flatten the structure into a single ScalableVectorType
+ auto *STy = cast<llvm::StructType>(Ty);
+ assert(STy->containsHomogeneousScalableVectorTypes() &&
+ isa<llvm::ScalableVectorType>(STy->getElementType(0)) &&
+ "Dealing with RVV tuple (aggregate with homogeneous scalable "
+ "vectors");
+
+ auto *VecTy = cast<llvm::ScalableVectorType>(STy->getElementType(0));
+
+ Ty = llvm::ScalableVectorType::get(VecTy->getScalarType(),
+ STy->getNumElements() *
+ VecTy->getMinNumElements());
----------------
eopXD wrote:
Yes, the initial approach will fall into this hazard. The updated approach to have them as the structure type we are expecting will avoid falling into this problem.
https://github.com/llvm/llvm-project/pull/67018
More information about the cfe-commits
mailing list