From owner-freebsd-numerics@FreeBSD.ORG Thu Mar 27 02:41:15 2014 Return-Path: Delivered-To: freebsd-numerics@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B95ED132 for ; Thu, 27 Mar 2014 02:41:15 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A8DEE91 for ; Thu, 27 Mar 2014 02:41:15 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.8/8.14.8) with ESMTP id s2R2fEQ5016047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Mar 2014 19:41:14 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.8/8.14.8/Submit) id s2R2fE7F016046; Wed, 26 Mar 2014 19:41:14 -0700 (PDT) (envelope-from sgk) Date: Wed, 26 Mar 2014 19:41:14 -0700 From: Steve Kargl To: "Montgomery-Smith, Stephen" Subject: Re: clang is almost useless for complex arithmetic Message-ID: <20140327024114.GA16009@troutmask.apl.washington.edu> References: <20140326002205.GA9940@troutmask.apl.washington.edu> <53338661.7060205@missouri.edu> <20140327020802.GA15862@troutmask.apl.washington.edu> <53338CB9.4030405@missouri.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53338CB9.4030405@missouri.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-numerics@freebsd.org" X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 02:41:15 -0000 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 algorithms. 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 #pragma. I also note that there are at least 4 bug reports about complex arithmetic in clang/llvm bug database. -- Steve