<div dir="ltr">A couple of other points on this patch.<div><br></div><div>- We could get a lot more out of these kinds of simplification, and generally improve the sanity of Clang's model here, by adding support for the C11 Imaginary type and using that to build up things. But this is more work than I can sign up for right now, and I'm not the best person to do it.</div><div><br></div><div>- You might wonder why not add a complex type to the IR so that the properties here are exposed at that level. There are some compelling reasons not to do this IMO.</div><div>  - Would need to "lower" this at some point which would be ugly. No chip (that LLVM supports) has complex registers and arithmetic operations....</div><div>  - Incredibly hard to change the IR in general, so bad cost/benefit tradeoff.</div><div><br></div><div>- While this patch handles the simplifications to complex arithmetic we can do when the typesystem itself shows one operand to be a real, it doesn't handle large other categories such as when inlining or other optimizations propagate away the imaginary part for example.</div><div>  - All of these should be easily caught by a target library optimization</div><div>  - I'll work on just such a target library pass to help polish off the last few missed optimzations.</div><div><br></div><div>- This has uncovered some nasty behavior with SROA. Need to fix that.....</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 9, 2014 at 3:16 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi hfinkel, scanon, resistor,<br>
<br>
...information.<br>
<br>
For both multiply and divide the old code was writing a long-hand<br>
reduced version of the math without any of the special handling of inf<br>
and NaN recommended by the standard here. Instead of putting more<br>
complexity here, this change does what GCC does which is to emit<br>
a libcall for the fully general case.<br>
<br>
However, the old code also failed to do the proper minimization of the<br>
set of operations when there was a mixed complex and real operation. In<br>
those cases, C provides a spec for much more minimal operations that are<br>
valid. Clang now emits the exact suggested operations. This change isn't<br>
*just* about performance though, without minimizing these operations, we<br>
again lose the correct handling of infinities and NaNs. It is critical<br>
that this happen in the frontend based on assymetric type operands to<br>
complex math operations.<br>
<br>
The performance implications of this change aren't trivial either. I've<br>
run a set of benchmarks in Eigen, an open source mathematics library<br>
that makes heavy use of complex. While a few have slowed down due to the<br>
libcall being introduce, most sped up and some by a huge amount.<br>
<br>
TODO: In order to make all of this work, also match the algorithm in the<br>
constant evaluator to the one in the runtime library. Currently it is a broken<br>
port of the simplifications from C's Annex G to the long-hand formulation of<br>
the algorithm.<br>
<br>
Splitting this patch up is very hard because none of this works without<br>
the AST change to preserve non-complex operands. Sorry for the enormous<br>
change.<br>
<br>
<a href="http://reviews.llvm.org/D5698" target="_blank">http://reviews.llvm.org/D5698</a><br>
<br>
Files:<br>
  lib/AST/ExprConstant.cpp<br>
  lib/CodeGen/CGExprComplex.cpp<br>
  lib/Sema/SemaExpr.cpp<br>
  test/CodeGen/complex-math.c<br>
<br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div>