[CLANG] Full support of complex multiplication and division. #81514
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -51,11 +51,12 @@ class ComplexExprEmitter | |
| CGBuilderTy &Builder; | ||
| bool IgnoreReal; | ||
| bool IgnoreImag; | ||
| LangOptions::ComplexRangeKind FPHasBeenPromoted; | ||
|
There was a problem hiding this comment. This is a somewhat misleading variable name. The name implies that it will be a Boolean value. |
||
|
|
||
| public: | ||
| ComplexExprEmitter(CodeGenFunction &cgf, bool ir = false, bool ii = false) | ||
| : CGF(cgf), Builder(CGF.Builder), IgnoreReal(ir), IgnoreImag(ii), | ||
| FPHasBeenPromoted(LangOptions::ComplexRangeKind::CX_None) {} | ||
|
|
||
| //===--------------------------------------------------------------------===// | ||
| // Utilities | ||
|
|
@@ -287,9 +288,54 @@ class ComplexExprEmitter | |
| ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName, | ||
| const BinOpInfo &Op); | ||
|
|
||
| QualType GetHigherPrecisionFPType(QualType ElementType) { | ||
| const auto *CurrentBT = dyn_cast<BuiltinType>(ElementType); | ||
| switch (CurrentBT->getKind()) { | ||
| case BuiltinType::Kind::Float16: | ||
| return CGF.getContext().FloatTy; | ||
| case BuiltinType::Kind::Float: | ||
| case BuiltinType::Kind::BFloat16: | ||
| return CGF.getContext().DoubleTy; | ||
| case BuiltinType::Kind::Double: | ||
| return CGF.getContext().LongDoubleTy; | ||
| default: | ||
| return ElementType; | ||
| } | ||
| } | ||
|
|
||
| QualType HigherPrecisionTypeForComplexArithmetic(QualType ElementType, | ||
| bool IsDivOpCode) { | ||
| QualType HigherElementType = GetHigherPrecisionFPType(ElementType); | ||
| const llvm::fltSemantics &ElementTypeSemantics = | ||
| CGF.getContext().getFloatTypeSemantics(ElementType); | ||
| const llvm::fltSemantics &HigherElementTypeSemantics = | ||
| CGF.getContext().getFloatTypeSemantics(HigherElementType); | ||
| // Check that LongDouble Size > Double Size. | ||
|
There was a problem hiding this comment. I'd word this as "Check that the promoted type can handle the intermediate values without overflowing." |
||
| // This can be interpreted as: | ||
| // SmallerType.LargestFiniteVal * SmallerType.LargestFiniteVal <= | ||
| // LargerType.LargestFiniteVal. | ||
|
There was a problem hiding this comment. Not entirely accurate, it's |
||
| // In terms of exponent it gives this formula: | ||
| // (SmallerType.LargestFiniteVal * SmallerType.LargestFiniteVal | ||
| // doubles the exponent of SmallerType.LargestFiniteVal); | ||
| if (llvm::APFloat::semanticsMaxExponent(ElementTypeSemantics) * 2 + 1 <= | ||
|
There was a problem hiding this comment. I'd appreciate a comment here explaining why this is the correct check, so that future people reading this code can understand why this is being doing. |
||
| llvm::APFloat::semanticsMaxExponent(HigherElementTypeSemantics)) { | ||
| return CGF.getContext().getComplexType(HigherElementType); | ||
| } else { | ||
| FPHasBeenPromoted = LangOptions::ComplexRangeKind::CX_Improved; | ||
|
There was a problem hiding this comment. If I'm following correctly, this means that the behavior wouldn't be right for this code: _Complex float func(_Complex float a, _Complex long double b, _Complex float c) {
return (_Complex float)(b / c) / a;
}The code would first process the long double complex division, which isn't promotable, and then the float division, using the same There was a problem hiding this comment. Yes I see the problem. Working on this. May be the There was a problem hiding this comment. I do see 2 different There was a problem hiding this comment. Can you add a test for this case? There was a problem hiding this comment. The test is at line #2319 of CodeGen/cx-complex-range.c. |
||
| DiagnosticsEngine &Diags = CGF.CGM.getDiags(); | ||
| Diags.Report(diag::warn_next_larger_fp_type_same_size_than_fp); | ||
| return CGF.getContext().getComplexType(ElementType); | ||
| } | ||
| } | ||
|
|
||
| QualType getPromotionType(QualType Ty, bool IsDivOpCode = false) { | ||
| if (auto *CT = Ty->getAs<ComplexType>()) { | ||
| QualType ElementType = CT->getElementType(); | ||
| if (IsDivOpCode && ElementType->isFloatingType() && | ||
| CGF.getLangOpts().getComplexRange() == | ||
| LangOptions::ComplexRangeKind::CX_Promoted) | ||
| return HigherPrecisionTypeForComplexArithmetic(ElementType, | ||
| IsDivOpCode); | ||
| if (ElementType.UseExcessPrecision(CGF.getContext())) | ||
| return CGF.getContext().getComplexType(CGF.getContext().FloatTy); | ||
| } | ||
|
|
@@ -300,11 +346,12 @@ class ComplexExprEmitter | |
|
|
||
| #define HANDLEBINOP(OP) \ | ||
| ComplexPairTy VisitBin##OP(const BinaryOperator *E) { \ | ||
| QualType promotionTy = getPromotionType( \ | ||
| E->getType(), \ | ||
| (E->getOpcode() == BinaryOperatorKind::BO_Div) ? true : false); \ | ||
| ComplexPairTy result = EmitBin##OP(EmitBinOps(E, promotionTy)); \ | ||
| if (!promotionTy.isNull()) \ | ||
| result = CGF.EmitUnPromotedValue(result, E->getType()); \ | ||
| return result; \ | ||
| } | ||
|
|
||
|
|
@@ -794,8 +841,10 @@ ComplexPairTy ComplexExprEmitter::EmitBinMul(const BinOpInfo &Op) { | |
| ResR = Builder.CreateFSub(AC, BD, "mul_r"); | ||
| ResI = Builder.CreateFAdd(AD, BC, "mul_i"); | ||
|
|
||
| if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Basic || | ||
| Op.FPFeatures.getComplexRange() == LangOptions::CX_Improved || | ||
| Op.FPFeatures.getComplexRange() == LangOptions::CX_Promoted || | ||
| CGF.getLangOpts().NoHonorInfs || CGF.getLangOpts().NoHonorNaNs) | ||
|
There was a problem hiding this comment. I'm not sure NoHonorInfs or NoHonorNaNs should be checked here. Given that we have explicit control for complex arithmetic behavior, maybe that should take precedence. That seems to be the way gcc handles it: https://godbolt.org/z/1oGo7jznz There was a problem hiding this comment. This code is in There was a problem hiding this comment. Oh, sorry, for some reason I thought this was invoking the special handling for division. I think the for honor NaNs and infinities still isn't necessary because we'll emit the comparison with the fast-math flags set and the backend will optimize it away, which is what happens today: https://godbolt.org/z/e8EnKodj6 |
||
| return ComplexPairTy(ResR, ResI); | ||
|
|
||
| // Emit the test for the real part becoming NaN and create a branch to | ||
|
|
@@ -986,14 +1035,17 @@ ComplexPairTy ComplexExprEmitter::EmitBinDiv(const BinOpInfo &Op) { | |
| llvm::Value *OrigLHSi = LHSi; | ||
| if (!LHSi) | ||
| LHSi = llvm::Constant::getNullValue(RHSi->getType()); | ||
| QualType ComplexElementTy = Op.Ty->castAs<ComplexType>()->getElementType(); | ||
| if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Improved || | ||
| (Op.FPFeatures.getComplexRange() == LangOptions::CX_Promoted && | ||
| FPHasBeenPromoted == LangOptions::CX_Improved)) | ||
|
There was a problem hiding this comment. It seems that this value is only ever set to CX_Improved or CX_None. Why not use a Boolean? As it is, I'm left with questions about what would happen if the value were CX_Basic or CX_None (expecting that CX_Promoted would be used if we did promote). There was a problem hiding this comment. I think may be using a boolean for this variable makes sense. It's only set when there is type promotion. In which case the name of the variable is appropriate? May be an even better name is |
||
| return EmitRangeReductionDiv(LHSr, LHSi, RHSr, RHSi); | ||
| else if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Basic || | ||
| Op.FPFeatures.getComplexRange() == LangOptions::CX_Promoted) | ||
| return EmitAlgebraicDiv(LHSr, LHSi, RHSr, RHSi); | ||
| // '-ffast-math' is used in the command line but followed by an | ||
| // '-fno-cx-limited-range' or '-fcomplex-arithmetic=full'. | ||
| else if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Full) { | ||
| LHSi = OrigLHSi; | ||
| // If we have a complex operand on the RHS and FastMath is not allowed, we | ||
| // delegate to a libcall to handle all of the complexities and minimize | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.