similar to: [LLVMdev] Inlining sqrt library function in X86

On May 17, 2013, at 3:33 PM, "Gurd, Preston" <preston.gurd at intel.com> wrote: > Using the following example program > > #include <math.h> > > double f(double d){ > return sqrt(d); > } > > and compiling it with “clang –O3 …”, I was trying to determine what it would take to get the X86 code generator to replace the call to sqrt with a

Does fast-math imply no-math-errno ? Thanks, Nadav On May 17, 2013, at 15:36, Chris Lattner <clattner at apple.com> wrote: > > On May 17, 2013, at 3:33 PM, "Gurd, Preston" <preston.gurd at intel.com> wrote: > >> Using the following example program >> >> #include <math.h> >> >> double f(double d){ >> return sqrt(d);

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

When you compile the attached file using llc -march=x86 -mcpu=atom sched-bug.ll -o - The Post-RA scheduler changes the sequence movl %ecx, (%esp) bsfl (%esp),%eax # this came from inline assembly code to read bsfl (%esp),%eax # this came from inline assembly code movl %ecx, (%esp) This is an incorrect schedule, because it seems the scheduler is not aware that the memory

My team interested in doing some post-RA optimizations on X86 instructions, which would require identifying memory reference instructions. In the X86 back end instructions, memory addresses consist of a set of five operands. The offset to the start of the five operands depends on the format of the instruction. For instance, the instructions ADC32rm, ADD32rm, AND32rm, ANDN32rm, CMOVA32rm,

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

In the course of implementing the instruction scheduler for the Intel Atom in LLVM, I have run across a problem with the critical anti-dependence breaker, whereby CriticalAntiDepBreak.cpp code changes some XMM0 references to be XMM9 references. This would be all well and good, were it not for the fact that the result of the expression needs to be in XMM0 because it is being returned as the

Hello Andy, Thank you for your offer to work together on implementing the your new scheduler on X86. I can start working on this right away. In case you were unaware, the new Silvermont micro-architecture is only out of order on the integer side. The SSE instructions are still in order, so the current postRA scheduler is very beneficial for code with lots of SSE instructions, such as the ISPC

When trying to run test/CodeGen/X86/liveness-local-regalloc.ll with the command line options "-optimize-regalloc=0 -verify-machineinstrs -mcpu-atom", the test fails right after the Post-RA pseudo instruction pass with the messages *** Bad machine code: Using an undefined physical register *** - function: autogen_SD24657 - basic block: BB 0x2662d60 (BB#0) - instruction:

Since Clang does not seem to allow type casts, such as uchar4 to float4, between vector types, it seems it is necessary to write them as element by element conversions, such as typedef float float4 __attribute__((ext_vector_type(4))); typedef unsigned char uchar4 __attribute__((ext_vector_type(4))); float4 to_float4(uchar4 in) { float4 out = {in.x, in.y, in.z, in.w}; return out; } Running

On Nov 20, 2008, at 8:31 AM, Preston Gurd wrote: > Might you instead consider just adding a -disable-mmx option? I agree, this is a better approach. This distinguishes between capabilities of the chip and the desire to codegen specific vectors one way or another. -Chris > > Preston > > On Thu, 2008-20-11 at 02:57 -0500, Mon Ping Wang wrote: >> Hi, >> >>

On 20/01/13 19:20, Caldarale, Charles R wrote: [...] > That's because there is no llvm.ceil.* intrinsic defined in include/llvm/Intrinsics.td for 3.2 Ah. Yes, that would explain it... does this mean that I can rely on all the intrinsics listed existing for the common types (int, float, double)? Or should I be trying to follow the libc call route? I've noticed that llc is successfully

Might you instead consider just adding a -disable-mmx option? Preston On Thu, 2008-20-11 at 02:57 -0500, Mon Ping Wang wrote: > Hi, > > When setting -mattr option on X86, I would like to treat MMX > separately from SSE levels. This would allow a client who sets the > attributes directly to set the SSE level independent of MMX, e.g., llc > -march=x86 -mattr=sse41, one would get

-----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of John Criswell Sent: Tuesday, September 11, 2012 1:42 PM To: Steve Checkoway Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] Need Help Understanding Operands in X86 MachineFunctionPass ... > >> The code for adding the 32-bit instruction is: >> >>

Hi, When setting -mattr option on X86, I would like to treat MMX separately from SSE levels. This would allow a client who sets the attributes directly to set the SSE level independent of MMX, e.g., llc -march=x86 -mattr=sse41, one would get sse4.1 with mmx disabled while llc -march=x86 -mattr=mmx -mattr=sse42 will get mmx and sse42. If anyone objects to this change, please let me

sqrtf is detected by code in SelectionDAGBuilder.cpp. This gets turns into a FSQRT ISD node type that the target can handle just like any other ISD node. If the target doesn't mark ISD::FSQRT as Legal or Custom then ExpandNode in LegalizeDAG.cpp turns it back into a sqrtf libcall. On Sun, Jan 20, 2013 at 11:34 AM, David Given <dg at cowlark.com> wrote: > On 20/01/13 19:20,

-- Preston Gurd <preston.gurd at intel.com> Intel Waterloo SSG/DPD/ECDL/DMP -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120409/b78a88d6/attachment.html>

In llvm.sqrt, why is the penalty for negative operands undefined behavior, as opposed to merely an unspecified result? As an example, in code like this: %x = call float @llvm.sqrt.f32(float %y) %z = fcmp oge float %y, -0.0 Does LLVM intend to reserve the right to assume that %z is always true? Or that %z is undef? Or even that any statement dominated by %x is unreachable? There's the

Hello, I have been gone for a while, finishing work on my Master's thesis... Now that I'm back I updated LLVM to the most recent version and found that my FP_ABS SelectionDAGNode type and code generation was now conflicting with the new FABS node type. I brought the rest of my local modifications in line with the FABS implementation, so here is my patch that includes sqrt, sin and cos

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