clang is almost useless for complex arithmetic
sgk at troutmask.apl.washington.edu
Thu Mar 27 02:41:15 UTC 2014
On Thu, Mar 27, 2014 at 02:28:13AM +0000, Montgomery-Smith, Stephen wrote:
> On 03/26/2014 09:08 PM, Steve Kargl wrote:
> > On Thu, Mar 27, 2014 at 02:01:08AM +0000, Montgomery-Smith, Stephen wrote:
> >> On 03/25/2014 07:22 PM, Steve Kargl wrote:
> >>> It appears that clang developers have chosen the naive
> >>> complex division algorithm, and it does not matter whether
> >>> one turns CX_LIMITED_RANGE on or off. This means that
> >>> if one uses clang with complex types, one must be careful
> >>> with the range of values allowed in complex division. In
> >>> other words, implementation of complex libm routines cannot
> >>> use complex data types and must fallback to a decomposition
> >>> into real and imaginary components.
> >> Could someone write a patch for clang to fix this?
> > Well, I certainly hope someone writes a patch. I don't
> > know the internals of llvm/clang/compiler_rt.
> I did a bit of grepping. Could it be that the division algorithm is
> contained in the file
> src/contrib/llvm/tools/clang/lib/CodeGen/CGExprComplex.cpp inside the
> function ComplexExprEmitter::EmitBinDiv ?
There are also files in compiler_rt/lib, which implement
complex division. It is unknown to me whether clang has
a builtin inlining procedure or clang generates calls to
a runtime library. Perhaps, the bahavior is target dependent?
> If you look at the code, it certainly looks like it is generating code
> to perform complex division, and it definitely looks like they are using
> the naive algorithm. Presumably even if one didn't fully understand the
> C++ used, one could do a "monkey sees - monkey does" change to the code,
> and then do some tests to see if it works.
> Although looking at figure 5 in http://arxiv.org/abs/1210.4539, it
> becomes clear that one has to include conditional in the generated code.
> so maybe you would need a bit of guidance from someone more expert in
> the clang compiler.
Yes, there are conditionals to avoid problems in the various
But, I'm actually surprised that the algorithm chosen isn't tied
to a compiler option (e.g., see gcc's -ffast-math) and/or to a
I also note that there are at least 4 bug reports about complex
arithmetic in clang/llvm bug database.
More information about the freebsd-numerics