maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/complex-math.c

474 lines
11 KiB
C
Raw Normal View History

[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
// RUN: %clang_cc1 %s -O1 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefix=X86
[complex] Use the much more powerful EmitCall routine to call libcalls for complex math. This should fix the windows build bots that started having trouble here and generally fix complex libcall emission on targets which use sret for complex data types. It also makes the code a bit simpler (despite calling into a much more complex bucket of code). llvm-svn: 219565
2014-10-11 17:24:41 +08:00
// RUN: %clang_cc1 %s -O1 -emit-llvm -triple x86_64-pc-win64 -o - | FileCheck %s --check-prefix=X86
// RUN: %clang_cc1 %s -O1 -emit-llvm -triple i686-unknown-unknown -o - | FileCheck %s --check-prefix=X86
complex long double support for PowerPC llvm-svn: 220034
2014-10-17 19:51:19 +08:00
// RUN: %clang_cc1 %s -O1 -emit-llvm -triple powerpc-unknown-unknown -o - | FileCheck %s --check-prefix=PPC
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
float _Complex add_float_rr(float a, float b) {
// X86-LABEL: @add_float_rr(
// X86: fadd
// X86-NOT: fadd
// X86: ret
return a + b;
}
float _Complex add_float_cr(float _Complex a, float b) {
// X86-LABEL: @add_float_cr(
// X86: fadd
// X86-NOT: fadd
// X86: ret
return a + b;
}
float _Complex add_float_rc(float a, float _Complex b) {
// X86-LABEL: @add_float_rc(
// X86: fadd
// X86-NOT: fadd
// X86: ret
return a + b;
}
float _Complex add_float_cc(float _Complex a, float _Complex b) {
// X86-LABEL: @add_float_cc(
// X86: fadd
// X86: fadd
// X86-NOT: fadd
// X86: ret
return a + b;
}
float _Complex sub_float_rr(float a, float b) {
// X86-LABEL: @sub_float_rr(
// X86: fsub
// X86-NOT: fsub
// X86: ret
return a - b;
}
float _Complex sub_float_cr(float _Complex a, float b) {
// X86-LABEL: @sub_float_cr(
// X86: fsub
// X86-NOT: fsub
// X86: ret
return a - b;
}
float _Complex sub_float_rc(float a, float _Complex b) {
// X86-LABEL: @sub_float_rc(
// X86: fsub
// X86: fsub float -0.{{0+}}e+00,
// X86-NOT: fsub
// X86: ret
return a - b;
}
float _Complex sub_float_cc(float _Complex a, float _Complex b) {
// X86-LABEL: @sub_float_cc(
// X86: fsub
// X86: fsub
// X86-NOT: fsub
// X86: ret
return a - b;
}
float _Complex mul_float_rr(float a, float b) {
// X86-LABEL: @mul_float_rr(
// X86: fmul
// X86-NOT: fmul
// X86: ret
return a * b;
}
float _Complex mul_float_cr(float _Complex a, float b) {
// X86-LABEL: @mul_float_cr(
// X86: fmul
// X86: fmul
// X86-NOT: fmul
// X86: ret
return a * b;
}
float _Complex mul_float_rc(float a, float _Complex b) {
// X86-LABEL: @mul_float_rc(
// X86: fmul
// X86: fmul
// X86-NOT: fmul
// X86: ret
return a * b;
}
float _Complex mul_float_cc(float _Complex a, float _Complex b) {
// X86-LABEL: @mul_float_cc(
[complex] Teach the complex math IR gen to emit direct math and a NaN-test prior to the call to the library function. This should automatically make fastmath (including just non-NaNs) able to avoid the expensive libcalls and also open the door to more advanced folding in LLVM based on the rules for complex math. Two important notes to remember: first is that this isn't yet a proper limited range mode, it's still just improving the unlimited range mode. Also, it isn't really perfecet w.r.t. what an unlimited range mode should be doing because it isn't quite handling the flags produced by all the operations in the way desirable for that mode, but then neither is compiler-rt's libcall. When the compiler-rt libcall is improved to carefully manage flags, the code emitted here should be improved correspondingly. And it is still a long-term desirable thing to add a limited range mode to Clang that would be able to use direct math without library calls here. Special thanks to Steve Canon for the careful review on this patch and teaching me about these issues. =D Differential Revision: http://reviews.llvm.org/D5756 llvm-svn: 220167
2014-10-20 03:13:49 +08:00
// X86: %[[AC:[^ ]+]] = fmul
// X86: %[[BD:[^ ]+]] = fmul
// X86: %[[AD:[^ ]+]] = fmul
// X86: %[[BC:[^ ]+]] = fmul
// X86: %[[RR:[^ ]+]] = fsub float %[[AC]], %[[BD]]
// X86: %[[RI:[^ ]+]] = fadd float
// X86-DAG: %[[AD]]
// X86-DAG: ,
// X86-DAG: %[[BC]]
// X86: fcmp uno float %[[RR]]
// X86: fcmp uno float %[[RI]]
[complex] Use the much more powerful EmitCall routine to call libcalls for complex math. This should fix the windows build bots that started having trouble here and generally fix complex libcall emission on targets which use sret for complex data types. It also makes the code a bit simpler (despite calling into a much more complex bucket of code). llvm-svn: 219565
2014-10-11 17:24:41 +08:00
// X86: call {{.*}} @__mulsc3(
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
// X86: ret
return a * b;
}
float _Complex div_float_rr(float a, float b) {
// X86-LABEL: @div_float_rr(
// X86: fdiv
// X86-NOT: fdiv
// X86: ret
return a / b;
}
float _Complex div_float_cr(float _Complex a, float b) {
// X86-LABEL: @div_float_cr(
// X86: fdiv
// X86: fdiv
// X86-NOT: fdiv
// X86: ret
return a / b;
}
float _Complex div_float_rc(float a, float _Complex b) {
// X86-LABEL: @div_float_rc(
// X86-NOT: fdiv
[complex] Use the much more powerful EmitCall routine to call libcalls for complex math. This should fix the windows build bots that started having trouble here and generally fix complex libcall emission on targets which use sret for complex data types. It also makes the code a bit simpler (despite calling into a much more complex bucket of code). llvm-svn: 219565
2014-10-11 17:24:41 +08:00
// X86: call {{.*}} @__divsc3(
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
// X86: ret
return a / b;
}
float _Complex div_float_cc(float _Complex a, float _Complex b) {
// X86-LABEL: @div_float_cc(
// X86-NOT: fdiv
[complex] Use the much more powerful EmitCall routine to call libcalls for complex math. This should fix the windows build bots that started having trouble here and generally fix complex libcall emission on targets which use sret for complex data types. It also makes the code a bit simpler (despite calling into a much more complex bucket of code). llvm-svn: 219565
2014-10-11 17:24:41 +08:00
// X86: call {{.*}} @__divsc3(
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
// X86: ret
return a / b;
}
double _Complex add_double_rr(double a, double b) {
// X86-LABEL: @add_double_rr(
// X86: fadd
// X86-NOT: fadd
// X86: ret
return a + b;
}
double _Complex add_double_cr(double _Complex a, double b) {
// X86-LABEL: @add_double_cr(
// X86: fadd
// X86-NOT: fadd
// X86: ret
return a + b;
}
double _Complex add_double_rc(double a, double _Complex b) {
// X86-LABEL: @add_double_rc(
// X86: fadd
// X86-NOT: fadd
// X86: ret
return a + b;
}
double _Complex add_double_cc(double _Complex a, double _Complex b) {
// X86-LABEL: @add_double_cc(
// X86: fadd
// X86: fadd
// X86-NOT: fadd
// X86: ret
return a + b;
}
double _Complex sub_double_rr(double a, double b) {
// X86-LABEL: @sub_double_rr(
// X86: fsub
// X86-NOT: fsub
// X86: ret
return a - b;
}
double _Complex sub_double_cr(double _Complex a, double b) {
// X86-LABEL: @sub_double_cr(
// X86: fsub
// X86-NOT: fsub
// X86: ret
return a - b;
}
double _Complex sub_double_rc(double a, double _Complex b) {
// X86-LABEL: @sub_double_rc(
// X86: fsub
// X86: fsub double -0.{{0+}}e+00,
// X86-NOT: fsub
// X86: ret
return a - b;
}
double _Complex sub_double_cc(double _Complex a, double _Complex b) {
// X86-LABEL: @sub_double_cc(
// X86: fsub
// X86: fsub
// X86-NOT: fsub
// X86: ret
return a - b;
}
double _Complex mul_double_rr(double a, double b) {
// X86-LABEL: @mul_double_rr(
// X86: fmul
// X86-NOT: fmul
// X86: ret
return a * b;
}
double _Complex mul_double_cr(double _Complex a, double b) {
// X86-LABEL: @mul_double_cr(
// X86: fmul
// X86: fmul
// X86-NOT: fmul
// X86: ret
return a * b;
}
double _Complex mul_double_rc(double a, double _Complex b) {
// X86-LABEL: @mul_double_rc(
// X86: fmul
// X86: fmul
// X86-NOT: fmul
// X86: ret
return a * b;
}
double _Complex mul_double_cc(double _Complex a, double _Complex b) {
// X86-LABEL: @mul_double_cc(
[complex] Teach the complex math IR gen to emit direct math and a NaN-test prior to the call to the library function. This should automatically make fastmath (including just non-NaNs) able to avoid the expensive libcalls and also open the door to more advanced folding in LLVM based on the rules for complex math. Two important notes to remember: first is that this isn't yet a proper limited range mode, it's still just improving the unlimited range mode. Also, it isn't really perfecet w.r.t. what an unlimited range mode should be doing because it isn't quite handling the flags produced by all the operations in the way desirable for that mode, but then neither is compiler-rt's libcall. When the compiler-rt libcall is improved to carefully manage flags, the code emitted here should be improved correspondingly. And it is still a long-term desirable thing to add a limited range mode to Clang that would be able to use direct math without library calls here. Special thanks to Steve Canon for the careful review on this patch and teaching me about these issues. =D Differential Revision: http://reviews.llvm.org/D5756 llvm-svn: 220167
2014-10-20 03:13:49 +08:00
// X86: %[[AC:[^ ]+]] = fmul
// X86: %[[BD:[^ ]+]] = fmul
// X86: %[[AD:[^ ]+]] = fmul
// X86: %[[BC:[^ ]+]] = fmul
// X86: %[[RR:[^ ]+]] = fsub double %[[AC]], %[[BD]]
// X86: %[[RI:[^ ]+]] = fadd double
// X86-DAG: %[[AD]]
// X86-DAG: ,
// X86-DAG: %[[BC]]
// X86: fcmp uno double %[[RR]]
// X86: fcmp uno double %[[RI]]
[complex] Use the much more powerful EmitCall routine to call libcalls for complex math. This should fix the windows build bots that started having trouble here and generally fix complex libcall emission on targets which use sret for complex data types. It also makes the code a bit simpler (despite calling into a much more complex bucket of code). llvm-svn: 219565
2014-10-11 17:24:41 +08:00
// X86: call {{.*}} @__muldc3(
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
// X86: ret
return a * b;
}
double _Complex div_double_rr(double a, double b) {
// X86-LABEL: @div_double_rr(
// X86: fdiv
// X86-NOT: fdiv
// X86: ret
return a / b;
}
double _Complex div_double_cr(double _Complex a, double b) {
// X86-LABEL: @div_double_cr(
// X86: fdiv
// X86: fdiv
// X86-NOT: fdiv
// X86: ret
return a / b;
}
double _Complex div_double_rc(double a, double _Complex b) {
// X86-LABEL: @div_double_rc(
// X86-NOT: fdiv
[complex] Use the much more powerful EmitCall routine to call libcalls for complex math. This should fix the windows build bots that started having trouble here and generally fix complex libcall emission on targets which use sret for complex data types. It also makes the code a bit simpler (despite calling into a much more complex bucket of code). llvm-svn: 219565
2014-10-11 17:24:41 +08:00
// X86: call {{.*}} @__divdc3(
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
// X86: ret
return a / b;
}
double _Complex div_double_cc(double _Complex a, double _Complex b) {
// X86-LABEL: @div_double_cc(
// X86-NOT: fdiv
[complex] Use the much more powerful EmitCall routine to call libcalls for complex math. This should fix the windows build bots that started having trouble here and generally fix complex libcall emission on targets which use sret for complex data types. It also makes the code a bit simpler (despite calling into a much more complex bucket of code). llvm-svn: 219565
2014-10-11 17:24:41 +08:00
// X86: call {{.*}} @__divdc3(
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
// X86: ret
return a / b;
}
long double _Complex add_long_double_rr(long double a, long double b) {
// X86-LABEL: @add_long_double_rr(
// X86: fadd
// X86-NOT: fadd
// X86: ret
return a + b;
}
long double _Complex add_long_double_cr(long double _Complex a, long double b) {
// X86-LABEL: @add_long_double_cr(
// X86: fadd
// X86-NOT: fadd
// X86: ret
return a + b;
}
long double _Complex add_long_double_rc(long double a, long double _Complex b) {
// X86-LABEL: @add_long_double_rc(
// X86: fadd
// X86-NOT: fadd
// X86: ret
return a + b;
}
long double _Complex add_long_double_cc(long double _Complex a, long double _Complex b) {
// X86-LABEL: @add_long_double_cc(
// X86: fadd
// X86: fadd
// X86-NOT: fadd
// X86: ret
return a + b;
}
long double _Complex sub_long_double_rr(long double a, long double b) {
// X86-LABEL: @sub_long_double_rr(
// X86: fsub
// X86-NOT: fsub
// X86: ret
return a - b;
}
long double _Complex sub_long_double_cr(long double _Complex a, long double b) {
// X86-LABEL: @sub_long_double_cr(
// X86: fsub
// X86-NOT: fsub
// X86: ret
return a - b;
}
long double _Complex sub_long_double_rc(long double a, long double _Complex b) {
// X86-LABEL: @sub_long_double_rc(
// X86: fsub
// X86: fsub x86_fp80 0xK8{{0+}},
// X86-NOT: fsub
// X86: ret
return a - b;
}
long double _Complex sub_long_double_cc(long double _Complex a, long double _Complex b) {
// X86-LABEL: @sub_long_double_cc(
// X86: fsub
// X86: fsub
// X86-NOT: fsub
// X86: ret
return a - b;
}
long double _Complex mul_long_double_rr(long double a, long double b) {
// X86-LABEL: @mul_long_double_rr(
// X86: fmul
// X86-NOT: fmul
// X86: ret
return a * b;
}
long double _Complex mul_long_double_cr(long double _Complex a, long double b) {
// X86-LABEL: @mul_long_double_cr(
// X86: fmul
// X86: fmul
// X86-NOT: fmul
// X86: ret
return a * b;
}
long double _Complex mul_long_double_rc(long double a, long double _Complex b) {
// X86-LABEL: @mul_long_double_rc(
// X86: fmul
// X86: fmul
// X86-NOT: fmul
// X86: ret
return a * b;
}
long double _Complex mul_long_double_cc(long double _Complex a, long double _Complex b) {
// X86-LABEL: @mul_long_double_cc(
[complex] Teach the complex math IR gen to emit direct math and a NaN-test prior to the call to the library function. This should automatically make fastmath (including just non-NaNs) able to avoid the expensive libcalls and also open the door to more advanced folding in LLVM based on the rules for complex math. Two important notes to remember: first is that this isn't yet a proper limited range mode, it's still just improving the unlimited range mode. Also, it isn't really perfecet w.r.t. what an unlimited range mode should be doing because it isn't quite handling the flags produced by all the operations in the way desirable for that mode, but then neither is compiler-rt's libcall. When the compiler-rt libcall is improved to carefully manage flags, the code emitted here should be improved correspondingly. And it is still a long-term desirable thing to add a limited range mode to Clang that would be able to use direct math without library calls here. Special thanks to Steve Canon for the careful review on this patch and teaching me about these issues. =D Differential Revision: http://reviews.llvm.org/D5756 llvm-svn: 220167
2014-10-20 03:13:49 +08:00
// X86: %[[AC:[^ ]+]] = fmul
// X86: %[[BD:[^ ]+]] = fmul
// X86: %[[AD:[^ ]+]] = fmul
// X86: %[[BC:[^ ]+]] = fmul
// X86: %[[RR:[^ ]+]] = fsub x86_fp80 %[[AC]], %[[BD]]
// X86: %[[RI:[^ ]+]] = fadd x86_fp80
// X86-DAG: %[[AD]]
// X86-DAG: ,
// X86-DAG: %[[BC]]
// X86: fcmp uno x86_fp80 %[[RR]]
// X86: fcmp uno x86_fp80 %[[RI]]
[complex] Use the much more powerful EmitCall routine to call libcalls for complex math. This should fix the windows build bots that started having trouble here and generally fix complex libcall emission on targets which use sret for complex data types. It also makes the code a bit simpler (despite calling into a much more complex bucket of code). llvm-svn: 219565
2014-10-11 17:24:41 +08:00
// X86: call {{.*}} @__mulxc3(
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
// X86: ret
complex long double support for PowerPC llvm-svn: 220034
2014-10-17 19:51:19 +08:00
// PPC-LABEL: @mul_long_double_cc(
[complex] Teach the complex math IR gen to emit direct math and a NaN-test prior to the call to the library function. This should automatically make fastmath (including just non-NaNs) able to avoid the expensive libcalls and also open the door to more advanced folding in LLVM based on the rules for complex math. Two important notes to remember: first is that this isn't yet a proper limited range mode, it's still just improving the unlimited range mode. Also, it isn't really perfecet w.r.t. what an unlimited range mode should be doing because it isn't quite handling the flags produced by all the operations in the way desirable for that mode, but then neither is compiler-rt's libcall. When the compiler-rt libcall is improved to carefully manage flags, the code emitted here should be improved correspondingly. And it is still a long-term desirable thing to add a limited range mode to Clang that would be able to use direct math without library calls here. Special thanks to Steve Canon for the careful review on this patch and teaching me about these issues. =D Differential Revision: http://reviews.llvm.org/D5756 llvm-svn: 220167
2014-10-20 03:13:49 +08:00
// PPC: %[[AC:[^ ]+]] = fmul
// PPC: %[[BD:[^ ]+]] = fmul
// PPC: %[[AD:[^ ]+]] = fmul
// PPC: %[[BC:[^ ]+]] = fmul
// PPC: %[[RR:[^ ]+]] = fsub ppc_fp128 %[[AC]], %[[BD]]
// PPC: %[[RI:[^ ]+]] = fadd ppc_fp128
// PPC-DAG: %[[AD]]
// PPC-DAG: ,
// PPC-DAG: %[[BC]]
// PPC: fcmp uno ppc_fp128 %[[RR]]
// PPC: fcmp uno ppc_fp128 %[[RI]]
complex long double support for PowerPC llvm-svn: 220034
2014-10-17 19:51:19 +08:00
// PPC: call {{.*}} @__multc3(
// PPC: ret
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
return a * b;
}
long double _Complex div_long_double_rr(long double a, long double b) {
// X86-LABEL: @div_long_double_rr(
// X86: fdiv
// X86-NOT: fdiv
// X86: ret
return a / b;
}
long double _Complex div_long_double_cr(long double _Complex a, long double b) {
// X86-LABEL: @div_long_double_cr(
// X86: fdiv
// X86: fdiv
// X86-NOT: fdiv
// X86: ret
return a / b;
}
long double _Complex div_long_double_rc(long double a, long double _Complex b) {
// X86-LABEL: @div_long_double_rc(
// X86-NOT: fdiv
[complex] Use the much more powerful EmitCall routine to call libcalls for complex math. This should fix the windows build bots that started having trouble here and generally fix complex libcall emission on targets which use sret for complex data types. It also makes the code a bit simpler (despite calling into a much more complex bucket of code). llvm-svn: 219565
2014-10-11 17:24:41 +08:00
// X86: call {{.*}} @__divxc3(
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
// X86: ret
complex long double support for PowerPC llvm-svn: 220034
2014-10-17 19:51:19 +08:00
// PPC-LABEL: @div_long_double_rc(
// PPC-NOT: fdiv
// PPC: call {{.*}} @__divtc3(
// PPC: ret
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
return a / b;
}
long double _Complex div_long_double_cc(long double _Complex a, long double _Complex b) {
// X86-LABEL: @div_long_double_cc(
// X86-NOT: fdiv
[complex] Use the much more powerful EmitCall routine to call libcalls for complex math. This should fix the windows build bots that started having trouble here and generally fix complex libcall emission on targets which use sret for complex data types. It also makes the code a bit simpler (despite calling into a much more complex bucket of code). llvm-svn: 219565
2014-10-11 17:24:41 +08:00
// X86: call {{.*}} @__divxc3(
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
// X86: ret
complex long double support for PowerPC llvm-svn: 220034
2014-10-17 19:51:19 +08:00
// PPC-LABEL: @div_long_double_cc(
// PPC-NOT: fdiv
// PPC: call {{.*}} @__divtc3(
// PPC: ret
[complex] Teach Clang to preserve different-type operands to arithmetic operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
2014-10-11 08:57:18 +08:00
return a / b;
}
[complex] Teach the other two binary operators on complex numbers (== and !=) to support mixed complex and real operand types. This requires removing an assert from SemaChecking, and adding support both to the constant evaluator and the code generator to synthesize the imaginary part when needed. This seemed somewhat cleaner than having just the comparison operators force real-to-complex conversions. I've added test cases for these operations. I'm really terrified that there were *no* tests in-tree which exercised this. This turned up when trying to build R after my change to the complex type lowering. llvm-svn: 219570
2014-10-11 19:03:30 +08:00
// Comparison operators don't rely on library calls or have interseting math
// properties, but test that mixed types work correctly here.
_Bool eq_float_cr(float _Complex a, float b) {
// X86-LABEL: @eq_float_cr(
// X86: fcmp oeq
// X86: fcmp oeq
// X86: and i1
// X86: ret
return a == b;
}
_Bool eq_float_rc(float a, float _Complex b) {
// X86-LABEL: @eq_float_rc(
// X86: fcmp oeq
// X86: fcmp oeq
// X86: and i1
// X86: ret
return a == b;
}
_Bool eq_float_cc(float _Complex a, float _Complex b) {
// X86-LABEL: @eq_float_cc(
// X86: fcmp oeq
// X86: fcmp oeq
// X86: and i1
// X86: ret
return a == b;
}
_Bool ne_float_cr(float _Complex a, float b) {
// X86-LABEL: @ne_float_cr(
// X86: fcmp une
// X86: fcmp une
// X86: or i1
// X86: ret
return a != b;
}
_Bool ne_float_rc(float a, float _Complex b) {
// X86-LABEL: @ne_float_rc(
// X86: fcmp une
// X86: fcmp une
// X86: or i1
// X86: ret
return a != b;
}
_Bool ne_float_cc(float _Complex a, float _Complex b) {
// X86-LABEL: @ne_float_cc(
// X86: fcmp une
// X86: fcmp une
// X86: or i1
// X86: ret
return a != b;
}