similar to: [LLVMdev] FP Intrinsics

Update: I have been working on this all day, and I finally got it working more or less with the pattern instruction selector... However, the generated code is not very good, and I haven't implemented the expand to calls if the target does not support these FP instructions. As an example, in the following function the sub abs and compare compiles to 13 instructions! Also it has changed the

On Wed, 16 Mar 2005, Morten Ofstad wrote: > Hello, > > I didn't get any reply to my previous mail about adding floating point > intrinsics to the X86 pattern instruction selector... And I could really need > some help. Sorry about that, it slipped through the cracks. :( > Anyway, I think my confusion was caused partly by an already > existing bug in the instruction

Hello, I didn't get any reply to my previous mail about adding floating point intrinsics to the X86 pattern instruction selector... And I could really need some help. Anyway, I think my confusion was caused partly by an already existing bug in the instruction selection for floating point compares. The case which emits code for the special case of comparing against constant 0.0 does not

On Fri, 11 Mar 2005, Morten Ofstad wrote: > Hello, > > I am trying to make the FP intrinsics (abs, sin, cos, sqrt) I've added work > with the X86ISelPattern, but I'm having some difficulties understanding what > needs to be done. Cool. Here are a couple of requests: 1. I don't think we need an "llvm.abs" intrinsic at the llvm level. This can be

Hello guys, Thanks for your help when you are busing. I am working on an open source project. It supports shader language and I want JIT feature, so LLVM is used. But now I find the ABI & Calling Convention did not co-work with MSVC. For example, following code I have: struct float4 { float x, y, z, w; }; struct float4x4 { float4 x, y, z, w; }; float4 fetch_vs( float4x4* mat

Hmm, I'm not able to get those .ll files to compile if I disable SSE and I end up with SSE instructions(including sqrtpd) if I don't disable it. On Thu, Jul 18, 2013 at 10:53 PM, Peter Newman <peter at uformia.com> wrote: > Is there something specifically required to enable SSE? If it's not > detected as available (based from the target triple?) then I don't think

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

Hmm, maybe sse isn't being enabled so its falling back to emulating sqrt? On Thu, Jul 18, 2013 at 10:45 PM, Peter Newman <peter at uformia.com> wrote: > In the disassembly, I'm seeing three cases of > call 76719BA1 > > I am assuming this is the sqrt function as this is the only function > called in the LLVM IR. > > The code at 76719BA1 is: > >

That should map directly to sqrtpd which can't modify ecx. On Thu, Jul 18, 2013 at 10:27 PM, Peter Newman <peter at uformia.com> wrote: > Sorry, that should have been llvm.x86.sse2.sqrt.pd > > > On 19/07/2013 3:25 PM, Craig Topper wrote: > > What is "frep.x86.sse2.sqrt.pd". I'm only familiar with things prefixed > with "llvm.x86". >

2013/10/19 Rafael Espíndola <rafael.espindola at gmail.com>: > On 19 October 2013 06:01, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com> wrote: >> I found that access llvm-mc from clang driver is impossible, and I >> want to use llvm-mc to compile assembly files, how to do that? > > Try "clang -integrated-as -c test.s" Thank you very much, I use the

In the disassembly, I'm seeing three cases of call 76719BA1 I am assuming this is the sqrt function as this is the only function called in the LLVM IR. The code at 76719BA1 is: 76719BA1 push ebp 76719BA2 mov ebp,esp 76719BA4 sub esp,20h 76719BA7 and esp,0FFFFFFF0h 76719BAA fld st(0) 76719BAC fst dword ptr [esp+18h] 76719BB0 fistp

Is there something specifically required to enable SSE? If it's not detected as available (based from the target triple?) then I don't think we enable it specifically. Also it seems that it should handle converting to/from the vector types, although I can see it getting confused about needing to do that if it thinks SSE isn't available at all. On 19/07/2013 3:47 PM, Craig Topper

Try adding ECX to the Defs of this part of lib/Target/X86/X86InstrCompiler.td like I've done below. I don't have a Windows machine to test myself. let Defs = [EAX, EDX, ECX, EFLAGS], FPForm = SpecialFP in { def WIN_FTOL_32 : I<0, Pseudo, (outs), (ins RFP32:$src), "# win32 fptoui", [(X86WinFTOL RFP32:$src)]>,

FAIL: /usr/home/llvm/obj/../test/Regression/CodeGen/X86/2004-02-22-Casts.llx: Assertion failed: (isNew && "Got into the map somehow?"), function AddLegalizedOperand, file /usr/home/llvm/obj/../lib/CodeGen/SelectionDAG/LegalizeDAG.cpp, line 79. .text .align 16 .globl test1 .type test1, @function test1: fldl 4(%esp) ftst

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

I don't think that's going to work. On Fri, Jul 19, 2013 at 12:24 AM, Peter Newman <peter at uformia.com> wrote: > Thank you, I'm trying this now. > > > On 19/07/2013 5:23 PM, Craig Topper wrote: > > Try adding ECX to the Defs of this part of > lib/Target/X86/X86InstrCompiler.td like I've done below. I don't have a > Windows machine to test

Jean-Marc Valin wrote: >If you set the denoiser to "on" and the VAD to "off", what difference >does it make in CPU time? > <p>Same program, running on Athlon XP 1700+: Test 1, using VAD, but AGC, denoise off: tevek@canarsie:~/work/hms/app_conference $ time ./vad_test /tmp/demo-instruct.sw 5 reading from /tmp/demo-instruct.sw, repeating 5 times read 537760

Hi everyone. On i386--win32 targets, LLVM tries to use the MSVCRT routine _ftol2 for floating-point to unsigned conversions, but this function has a nonstandard calling convention LLVM doesn't understand. It takes its input operand on the x87 stack as ST0, which it pops off of the stack before returning. The return value is given in EDX:EAX. In effect, I need to call it like this: %1 = call

Here's my attempt at a fix. Adding Jakob to make sure I did this right. On Fri, Jul 19, 2013 at 2:34 AM, Peter Newman <peter at uformia.com> wrote: > That does appear to have worked. All my tests are passing now. > > I'll hand this out to our other devs & testers and make sure it's working > for them as well (not just on my machine). > > Thank you,

I can confirm I get the same behavior, and that's a real bug. If you use --target=i686-pc-win32, you get COFF, and that should be a good workaround for now. There must be a conditional somewhere that isn't handling mingw correctly. On Sat, Oct 19, 2013 at 7:58 AM, 罗勇刚(Yonggang Luo) <luoyonggang at gmail.com>wrote: > 2013/10/19 Rafael Espíndola <rafael.espindola at