-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CLANG] Full support of complex multiplication and division. #81514
Changes from 1 commit
13fd739
eb9a35c
d3c4f78
4aa0925
fcd5665
2ddba9a
e62c462
f635f94
1d61aa6
148b6ce
5aa2711
ba9a8da
9098908
52181c7
a9449de
e20741e
0d97b9b
bc3fa4f
ec6296f
3117dbd
0a08598
a558d31
dec045b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -1847,19 +1847,25 @@ floating point semantic models: precise (the default), strict, and fast. | |||||
* ``16`` - Forces ``_Float16`` operations to be emitted without using excess | ||||||
precision arithmetic. | ||||||
|
||||||
.. option:: -fcx-limited-range: | ||||||
|
||||||
This option enables the naive mathematical formulas for complex division and | ||||||
multiplication with no NaN checking of results. The default is | ||||||
``-fno-cx-limited-range``, but this option is enabled by the ``-ffast-math`` | ||||||
option. | ||||||
|
||||||
.. option:: -fcx-fortran-rules: | ||||||
|
||||||
This option enables the naive mathematical formulas for complex | ||||||
multiplication and enables application of Smith's algorithm for complex | ||||||
division. See SMITH, R. L. Algorithm 116: Complex division. Commun. | ||||||
ACM 5, 8 (1962). The default is ``-fno-cx-fortran-rules``. | ||||||
.. option:: -fcomplex-arithmetic=<value>: | ||||||
|
||||||
This option specifies the implementation for complex multiplication and division. | ||||||
|
||||||
Valid values are: ``limited``, ``smith``, ``full`` and ``extend``. | ||||||
|
||||||
* ``limited`` Implementation of complex division and multiplication using | ||||||
algebraic formulas at source precision. Overflow and non-finites values | ||||||
are not handled. | ||||||
* ``smith`` Implementation of complex division using the Smith algorithm at | ||||||
source precision. Smith's algorithm for complex division. | ||||||
See SMITH, R. L. Algorithm 116: Complex division. Commun. ACM 5, 8 (1962). | ||||||
Overflow is handled. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There are some cases at the extreme end of the value range where overflow can still occur. I think this should say that it offers improved handling for overflow in intermediate calculations, but mention that overflow is still possible. We should also mention that this does not handle non-finite values in all cases. |
||||||
* ``full`` Implementation of complex division and multiplication using a | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What are we doing with fast-math flags in these expansions? In the case of complex multiplication, if the 'nnan' and 'ninf' flags are set on the generated instructions, the "full" implementation will be optimized to the "basic" implementation. I think that's probably what we want since "full" is going to be the default. It may warrant a warning if we see an explicit "-fcomplex-arithmetic=full" on the command line with any of the options that sets either 'nnan' or 'ninf'. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. -ffast-math implies "basic". In the case of complex multiplication, if the 'nnan' and 'ninf' flags are set on the generated instructions, the "full" implementation will be optimized to the "basic" implementation. This is not the case currently. I will add that. |
||||||
call to runtime library functions (generally the case, but the BE might | ||||||
sometimes replace the library call if it knows enough about the potential | ||||||
range of the inputs). Overflow and non-finite values are handled. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
I want to emphasize the location of the handling because I found a case where the current LLVM library function overflows with complex division. |
||||||
* ``extend`` Implementation of complex division using algebraic formulas at | ||||||
higher precision. Overflow is handled. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again, explicitly mention that non-finite values are not handled in all cases. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is probably worth adding an example to illustrate both the overflow and non-finite handling cases so users can properly understand the risk of ignoring those cases. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You should specify that "full" is the default. |
||||||
|
||||||
.. _floating-point-environment: | ||||||
|
||||||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1012,28 +1012,15 @@ defm offload_uniform_block : BoolFOption<"offload-uniform-block", | |
NegFlag<SetFalse, [], [ClangOption, CC1Option], "Don't assume">, | ||
BothFlags<[], [ClangOption], " that kernels are launched with uniform block sizes (default true for CUDA/HIP and false otherwise)">>; | ||
|
||
def fcx_limited_range : Joined<["-"], "fcx-limited-range">, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I didn't realize these had made it into the 18.0 release when I suggested that we could remove them. We would need at least one release where they are marked as deprecated, but since they are standard gcc options, maybe it makes sense to just keep them and have them alias to the new option as: -fcx-limited-range --> -fcomplex-arithmetic=basic There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The problem with aliasing is that the user would be allowed to write something like this: This warning is a bit mis-leading and doesn't reflect the option used in the command line. Not sure this can be corrected. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry. I meant "aliasing" in the non-technical sense of "having the same meaning." How that gets implemented is another matter. I think the driver could translate them to the same cc1 option. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes there is a way of doing that:
That still produces the misleading warning for: -fcx-limited-range -fcomplex-arithmetic=improved There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What I meant to suggest is that you can leave the driver-level options as if they were independent, but when we process them in RenderFloatingPointOptions, -fcx-limited-range and -fcomplex-arithmetic=basic (for example), would add the same cc1 option. Since the warning is generated from the RenderFloatingPointOptions we should be able to make that report the expected output. |
||
Group<f_Group>, Visibility<[ClangOption, CC1Option]>, | ||
HelpText<"Basic algebraic expansions of complex arithmetic operations " | ||
"involving are enabled.">; | ||
|
||
def fno_cx_limited_range : Joined<["-"], "fno-cx-limited-range">, | ||
Group<f_Group>, Visibility<[ClangOption, CC1Option]>, | ||
HelpText<"Basic algebraic expansions of complex arithmetic operations " | ||
"involving are disabled.">; | ||
|
||
def fcx_fortran_rules : Joined<["-"], "fcx-fortran-rules">, | ||
Group<f_Group>, Visibility<[ClangOption, CC1Option]>, | ||
HelpText<"Range reduction is enabled for complex arithmetic operations.">; | ||
|
||
def fno_cx_fortran_rules : Joined<["-"], "fno-cx-fortran-rules">, | ||
Group<f_Group>, Visibility<[ClangOption, CC1Option]>, | ||
HelpText<"Range reduction is disabled for complex arithmetic operations.">; | ||
def fcomplex_arithmetic_EQ : Joined<["-"], "fcomplex-arithmetic=">, Group<f_Group>, | ||
Visibility<[ClangOption, CC1Option]>, | ||
Values<"full,smith,extend,limited">, NormalizedValuesScope<"LangOptions">, | ||
NormalizedValues<["CX_Full", "CX_Smith", "CX_Extend", "CX_Limited"]>; | ||
|
||
def complex_range_EQ : Joined<["-"], "complex-range=">, Group<f_Group>, | ||
Visibility<[CC1Option]>, | ||
Values<"full,limited,fortran">, NormalizedValuesScope<"LangOptions">, | ||
NormalizedValues<["CX_Full", "CX_Limited", "CX_Fortran"]>, | ||
Values<"full,smith,extend,limited">, NormalizedValuesScope<"LangOptions">, | ||
NormalizedValues<["CX_Full", "CX_Smith", "CX_Extend", "CX_Limited"]>, | ||
MarshallingInfoEnum<LangOpts<"ComplexRange">, "CX_Full">; | ||
|
||
// OpenCL-only Options | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -283,9 +283,23 @@ class ComplexExprEmitter | |
ComplexPairTy EmitComplexBinOpLibCall(StringRef LibCallName, | ||
const BinOpInfo &Op); | ||
|
||
QualType getPromotionType(QualType Ty) { | ||
QualType getPromotionType(QualType Ty, bool IsDivOpCode = false) { | ||
if (auto *CT = Ty->getAs<ComplexType>()) { | ||
QualType ElementType = CT->getElementType(); | ||
if (CGF.getLangOpts().getComplexRange() == | ||
LangOptions::ComplexRangeKind::CX_Extend && | ||
IsDivOpCode) { | ||
if (ElementType->isFloatingType()) { | ||
if (const auto *BT = dyn_cast<BuiltinType>(ElementType)) | ||
switch (BT->getKind()) { | ||
case BuiltinType::Kind::Float: | ||
return CGF.getContext().getComplexType(CGF.getContext().DoubleTy); | ||
default: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This doesn't look general enough. I'm not sure how to implement this. We need some handling for fp16 and fp128. I guess fp16 would promote to float, but fp128 will require using runtime library calls. For Windows, double and long double are the same by default. Does the front end have a way to specifically recognize x86_fp80 and ppc_fp128? Will something in Sema prevent us from getting here with bf16? |
||
return CGF.getContext().getComplexType( | ||
CGF.getContext().LongDoubleTy); | ||
} | ||
} | ||
} | ||
if (ElementType.UseExcessPrecision(CGF.getContext())) | ||
return CGF.getContext().getComplexType(CGF.getContext().FloatTy); | ||
} | ||
|
@@ -296,11 +310,12 @@ class ComplexExprEmitter | |
|
||
#define HANDLEBINOP(OP) \ | ||
ComplexPairTy VisitBin##OP(const BinaryOperator *E) { \ | ||
QualType promotionTy = getPromotionType(E->getType()); \ | ||
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()); \ | ||
result = CGF.EmitUnPromotedValue(result, E->getType()); \ | ||
return result; \ | ||
} | ||
|
||
|
@@ -790,7 +805,8 @@ ComplexPairTy ComplexExprEmitter::EmitBinMul(const BinOpInfo &Op) { | |
ResI = Builder.CreateFAdd(AD, BC, "mul_i"); | ||
|
||
if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Limited || | ||
Op.FPFeatures.getComplexRange() == LangOptions::CX_Fortran) | ||
Op.FPFeatures.getComplexRange() == LangOptions::CX_Smith || | ||
Op.FPFeatures.getComplexRange() == LangOptions::CX_Extend) | ||
return ComplexPairTy(ResR, ResI); | ||
|
||
// Emit the test for the real part becoming NaN and create a branch to | ||
|
@@ -981,9 +997,10 @@ ComplexPairTy ComplexExprEmitter::EmitBinDiv(const BinOpInfo &Op) { | |
llvm::Value *OrigLHSi = LHSi; | ||
if (!LHSi) | ||
LHSi = llvm::Constant::getNullValue(RHSi->getType()); | ||
if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Fortran) | ||
if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Smith) | ||
return EmitRangeReductionDiv(LHSr, LHSi, RHSr, RHSi); | ||
else if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Limited) | ||
else if (Op.FPFeatures.getComplexRange() == LangOptions::CX_Limited || | ||
Op.FPFeatures.getComplexRange() == LangOptions::CX_Extend) | ||
return EmitAlgebraicDiv(LHSr, LHSi, RHSr, RHSi); | ||
else if (!CGF.getLangOpts().FastMath || | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should remove the fast-math check here. The driver handling of fast-math sets the complex arithmetic option. This check has always been problematic because disabling just one component of fast-math (such as enabling signed zeros) causes this to be false. |
||
// '-ffast-math' is used in the command line but followed by an | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's accurate to say that "non-finite values are not handled." I would say instead that infinite values are not handled correctly in all cases.