[LLVMdev] Inlining sqrt library function in X86
preston.gurd at intel.com
Tue May 21 15:10:38 PDT 2013
If I do not use the -ffast-math, then the generated code calls "sqrt". If I do use -ffast-math, then the code calls __sqrt_finite.
The use of -ffast-math seems to result in gcc's math.h including /usr/include/x86_64-linux-gnu/bits/math-finite.h, which (I am guessing!) redfines sqrt as "__sqrt_finite".
From: Benjamin Kramer [mailto:benny.kra at gmail.com]
Sent: Tuesday, May 21, 2013 5:15 PM
To: Gurd, Preston
Cc: Chandler Carruth; Nadav Rotem; LLVMdev (LLVMdev at cs.uiuc.edu)
Subject: Re: [LLVMdev] Inlining sqrt library function in X86
On 21.05.2013, at 23:03, "Gurd, Preston" <preston.gurd at intel.com> wrote:
> Thanks for the fix!
> However, there still seems to be a problem in that if you pass -ffast-math to clang, then clang changes "sqrt" to be "__sqrt_finite". LLVM cannot then change the function call into an x86 sqrt instruction, even with -fno-math-errno set.
> Can you suggest where I might look in the clang code to find the place where "sqrt" is converted to "__sqrt_finite" and/or the best way to solve this problem?
This sounds like your system headers are trying to outsmart the compiler, clang doesn't generate calls to __sqrt_finite anywhere. We may have to recognize the pattern in LLVM or clang if we want to inline calls to sqrt. A first step would be to figure out where the headers are doing this and whether there's a way to disable it.
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf OfChandler Carruth
> Sent: Saturday, May 18, 2013 4:48 PM
> To: Nadav Rotem
> Cc: LLVMdev (LLVMdev at cs.uiuc.edu)
> Subject: Re: [LLVMdev] Inlining sqrt library function in X86
> On Sat, May 18, 2013 at 5:18 PM, Nadav Rotem <nrotem at apple.com> wrote:
> Does fast-math imply no-math-errno ?
> Yes, in both GCC and Clang. Clang does have some annoying logic bugs surrounding this flag though. For example, setting -fno-fast-math would imply no-math-errno, overriding the Linux default. Quite weird. I've cleaned this up some and added more clear tests in r182203.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev