================
@@ -283,9 +283,46 @@ class ComplexExprEmitter
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName,
const BinOpInfo &Op);
- QualType getPromotionType(QualType Ty) {
+ QualType HigherPrecisionTypeForComplexArithmetic(QualType ElementType,
+ bool IsDivOpCode) {
+ const TargetInfo &TI = CGF.getContext().getTargetInfo();
+ const LangOptions Opts = CGF.getLangOpts();
+ if (const auto *BT = dyn_cast<BuiltinType>(ElementType)) {
+ switch (BT->getKind()) {
+ case BuiltinType::Kind::Float16: {
+ if (TI.hasFloat16Type() && !TI.hasLegalHalfType())
+ return CGF.getContext().getComplexType(CGF.getContext().FloatTy);
+ break;
+ }
+ case BuiltinType::Kind::BFloat16: {
+ if (TI.hasBFloat16Type() && !TI.hasFullBFloat16Type())
+ return CGF.getContext().getComplexType(CGF.getContext().FloatTy);
+ break;
+ }
+ case BuiltinType::Kind::Float:
+ return CGF.getContext().getComplexType(CGF.getContext().DoubleTy);
+ break;
+ case BuiltinType::Kind::Double: {
+ if (TI.hasLongDoubleType())
+ return
CGF.getContext().getComplexType(CGF.getContext().LongDoubleTy);
+ return CGF.getContext().getComplexType(CGF.getContext().DoubleTy);
----------------
andykaylor wrote:
Yes, we need to check the sizes. If we "promote" from a 64-bit double to a
64-bit long double, we'll probably end up with something that gets optimized
directly to the cx-limited-range ("basic") implementation. This can also be an
issue for float. For example, AVR targets use a 32-bit type for both float and
double.
https://github.com/llvm/llvm-project/pull/81514
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
