similar to: [LLVMdev] pow operator on Windows

On 12/02/11 04:52, Michael Smith wrote: [...] > With "gcc test.c; ./a.exe", the printed result is 6.50260946378542390000 > With "clang -emit-llvm -c test.c -o test.bc; lli test.bc", the printed result is 6.50260946378542480000 The x86 has got several different FPU instruction sets, which don't all work at the same precision. In particular, using 387 instructions uses

On 2011-02-12 12:34, David Given wrote: ... > You might want to look at the generated machine code to see how they > differ. If this *is* the problem, you can tell gcc to use a particular > instruction set with -mfpmath=386 or -mfpmath=sse. I think you mean -mfpmath=387, instead. :) Btw, this option is also not supported by clang... any idea how it could be implemented, if at all?

On Sat, Feb 12, 2011 at 1:06 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 2011-02-12 12:34, David Given wrote: >> You might want to look at the generated machine code to see how they >> differ. If this *is* the problem, you can tell gcc to use a particular >> instruction set with -mfpmath=386 or -mfpmath=sse. > > I think you mean -mfpmath=387, instead. :)

> On Jan 12, 2017, at 12:58 PM, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/12/2017 9:33 AM, Mehdi Amini via llvm-dev wrote: >>> On Jan 12, 2017, at 5:03 AM, Antoine Pitrou via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Mon, 9 Jan 2017 11:43:17 -0600 >>> Wei Ding via llvm-dev <llvm-dev at

> On Jan 12, 2017, at 5:03 AM, Antoine Pitrou via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, 9 Jan 2017 11:43:17 -0600 > Wei Ding via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hi, >> >> I want an efficient way to implement function pow in LLVM instead of >> invoking pow() math built-in. For algorithm part, I am clear for the

> On Jan 12, 2017, at 2:21 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > >> On Jan 12, 2017, at 11:04 AM, Steve (Numerics) Canon <scanon at apple.com <mailto:scanon at apple.com>> wrote: >> >>> >>> On Jan 12, 2017, at 12:58 PM, Friedman, Eli via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>

Hi, I want an efficient way to implement function pow in LLVM instead of invoking pow() math built-in. For algorithm part, I am clear for the logic. But I am not quite sure for which parts of LLVM should I replace built-in pow with another efficient pow implementation. Any comments and feedback are appreciated. Thanks! -- Wei Ding -------------- next part -------------- An HTML attachment was

Hi, Current llvm-gcc cannot emit llvm intrinsic function like llvm.pow.* and llvm.sin.* For example: double foo(double x, double y) { return pow(x,y); } will compiled into ll: define double @foo(double %x, double %y) { %tmp3 = tail call double @pow( double %x, double %y ) ret double %tmp3 } This is not consistent with llvm language reference. -------------- next part -------------- An

Hi, > Current llvm-gcc cannot emit llvm intrinsic function like llvm.pow.* and > llvm.sin.* > For example: > > double foo(double x, double y) { > return pow(x,y); > } > > will compiled into ll: > > define double @foo(double %x, double %y) { > %tmp3 = tail call double @pow( double %x, double %y ) > ret double %tmp3 > } > > This is not

2007/11/22, Duncan Sands <baldrick at free.fr>: > > Hi, > > > Current llvm-gcc cannot emit llvm intrinsic function like llvm.pow.* and > > llvm.sin.* > > For example: > > > > double foo(double x, double y) { > > return pow(x,y); > > } > > > > will compiled into ll: > > > > define double @foo(double %x, double %y) {

PS: It is possible that the C front-end doesn't need to explicitly produce BUILT_IN_POW because it is auto-synthesized somehow from a call to "pow". I wouldn't know. One way to find out is to compile a testcase and rummage around inside the gcc trees when they hit llvm-convert.

Hi, 2007/11/22, Duncan Sands <baldrick at free.fr>: > > PS: It is possible that the C front-end doesn't need to > explicitly produce BUILT_IN_POW because it is auto-synthesized > somehow from a call to "pow". I wouldn't know. One way to > find out is to compile a testcase and rummage around inside > the gcc trees when they hit llvm-convert. Yes, they

Hi, > Sure. But now the question is the llvm-gcc will not emit llvm.pow.* anytime. indeed there seems to be no code in llvm-gcc to do so, though there is code for raising to an integer power (in llvm-convert). Please feel free to investigate and add some. Presumably it should turn gcc's BUILT_IN_POW into llvm.pow.*. That said, as far as I can see the C front-end doesn't generate

On 2/7/14, 10:24 AM, Andrew Trick wrote: > > On Feb 5, 2014, at 12:54 AM, Mehdi Amini <mehdi.amini at silkan.com > <mailto:mehdi.amini at silkan.com>> wrote: > >> Hi, >> >> I was looking at some bugs to play with, and I started with >> http://llvm.org/bugs/show_bug.cgi?id=18606 >> >> As I commented there, a loop is unrolled and exhibit

https://bugs.freedesktop.org/show_bug.cgi?id=89758 Bug ID: 89758 Summary: pow WebGL Conformance test with mesa drivers Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

Hi, I was looking at some bugs to play with, and I started with http://llvm.org/bugs/show_bug.cgi?id=18606 As I commented there, a loop is unrolled and exhibit this pattern: %mul.1 = mul i32 %mul, %mul %mul.2 = mul i32 %mul.1, %mul.1 .... With an unroll factor of 32, the last multiply has 2^32 terms in its SCEV expression. (I mean I expect it would have those terms if I was patient

More specifically, about this patch: http://git.xiph.org/?p=flac.git;a=commitdiff;h=70b078cfd5f9d4b0692c33f018cac3c652b14f90 I downloaded the latest code from git (flac-70b078c), disabled all SSE optimizations in the code and compiled it (GCC 4.8.2). This patch doesn't change FLAC output. Either gcc is too smart and optimizes this new code back to the old, or this fix is MSVS-specific. Or

Dear LLVM contributors, I am Naoki Shibata, an associate professor at Nara Institute of Science and Technology. I and Hal Finkel would like to jointly propose to add my vectorized math library to LLVM. The library has been available as public domain software for years, I am going to double-license the library if necessary. ******** Below is a proposal to add my vectorized math library,

Olivier Tristan <o.tristan at uvi.net> ?????(?) ? ????? ?????? Fri, 21 Mar 2014 22:41:00 +0400: > Check with -mfpmath=387 to be sure that x87 FPU code is used and not some > SSE optim made by GCC I added "XIPH_ADD_CFLAGS([-mfpmath=387])" into configure.ac Still the result is different from SSE version. --------------- MSVS adds two instructions to the generated code after

On 22 March 2016 at 11:34, James Molloy <James.Molloy at arm.com> wrote: > I don’t think this part is right. The denormal flag would have to be set by > whatever code generates the FP instruction, which would be Clang’s codegen > layer. So the if (Darwin) would be there, not in TTI. Right, I meant the information to set/not set would be in TTI, not the actual setting. I don't